Dependency Injection (concepts & Spring basics)

Dependency injection is the technique of giving an object the collaborators it needs from the outside — through its constructor — instead of having it create them itself, which decouples your code and makes it far easier to test.

Learn Dependency Injection (concepts & Spring basics) in our free Java course — a beginner-friendly interactive lesson with worked examples, a practice…

Part of the free Java course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

Before You Start

You should be comfortable with interfaces (DI depends on programming to abstractions) and constructors . A look at lambdas helps for the functional-interface examples.

What You'll Learn

The Big Idea — Power Sockets, Not Soldered Wires

💡 Analogy: A class that new s its own dependencies is like a lamp with its power cable soldered straight into the wall — it works, but you can never move it, test it on a bench, or swap the bulb's power source. Dependency injection gives the lamp a plug and the wall a socket : the lamp just declares "I need power" and whoever installs it decides what to plug in — mains power, a battery pack, or a test rig. The lamp doesn't change; only what you plug in does.

"Inversion of Control" is simply this idea: the lamp no longer controls where its power comes from — an outside installer does.

1️⃣ The Problem — Hard-Wired Dependencies

When a class builds its own collaborators with new , it is welded to that exact implementation. You can't swap EmailService for an SMS one, and you certainly can't test the class without triggering the real thing. That is tight coupling .

2️⃣ The Fix — Constructor Injection

Depend on an interface and receive the implementation through the constructor. Now the same OrderService works with an email notifier, an SMS notifier, or anything else — and the caller (a manual "injector") decides which to plug in.

3️⃣ The Payoff — Testability

Because the dependency is an interface passed in, a test can inject a fake that records calls instead of doing real work. You can then assert exactly what the class did — with no email server, no network, no flakiness.

4️⃣ How Spring Automates the Wiring

In a small program you do the wiring in main . In a large app that quickly becomes a tangle, so frameworks like Spring provide a container that wires everything for you. You annotate classes as beans with @Component / @Service , and Spring constructs the object graph and injects dependencies — often just by spotting the constructor (so @Autowired is optional on a single constructor).

🧠 Quick Recall

Answer: control over creating and wiring collaborators. Instead of the class deciding what to new , an outside party (your code or a container) decides and supplies it.

Answer: so any implementation — real or fake — can be injected. Depending on the concrete class re-couples you to it and blocks substitution.

Answer: because it's set once in the constructor and never reassigned. final documents that, prevents accidental rebinding, and guarantees the object is fully initialised.

🎯 YOUR TURN — Inject a Logger

Make Calculator depend on the Logger interface via constructor injection, store it final , and log each addition.

🧩 MINI-CHALLENGE — Two injected collaborators

Build a CheckoutService that takes a PaymentGateway and a Receipts recorder, wired with lambdas in main .

Common Errors

• ❌ new-ing dependencies inside the class. It welds you to one implementation. Fix: accept the dependency through the constructor.
• ❌ Depending on a concrete class, not an interface. Substitution becomes impossible. Fix: program to an interface.
• ❌ Field injection everywhere. Hides dependencies and breaks plain-Java tests. Fix: prefer constructor injection.
• ❌ Too many constructor parameters. Often a sign a class does too much. Fix: split responsibilities or group related deps.
• ❌ Thinking you need a framework. DI is a design idea. Fix: wire by hand in small apps; reach for Spring at scale.
• ❌ Service locators / global singletons. They hide dependencies and reintroduce coupling. Fix: pass dependencies in explicitly.

Pro Tips

• 💡 Constructor-inject and mark fields final. Explicit, immutable, always-valid objects.
• 💡 One-method interfaces are functional — you can inject a lambda directly as a quick fake or real impl.
• 💡 In Spring, a single constructor needs no @Autowired — the container infers it.
• 💡 Keep wiring at the edges (main, a config class, or the container) so your business classes stay free of construction logic.

📋 Quick Reference

Concept

Syntax / idea

Note

tight coupling

new EmailService()

Avoid inside business classes

abstraction

interface Notifier

Depend on this

constructor injection

Svc(Notifier n)

Preferred form

final field

private final Notifier n;

Set once, never null

manual injector

new Svc(new Email())

Wiring in main

test double

new Svc(fake)

No real I/O

IoC

control moves outward

DI implements it

Spring bean

@Component / @Service

Container-managed

Spring inject

@Autowired

Optional on 1 ctor

benefit

decoupling + testability

The whole point

avoid

field injection, singletons

Hide dependencies

📚 Resources / Keep Learning

• 📘 FunctionalInterface — Java 21 API (docs.oracle.com)
• 📗 Using Interfaces — dev.java tutorial
• 📗 dev.java — official tutorials and guides

❓ Frequently Asked Questions

🎉 Lesson Complete!

You now understand Inversion of Control, why hard-wired new dependencies hurt, how to apply constructor injection against an interface in plain Java, how that unlocks easy testing with fakes, and how Spring's @Component / @Autowired automate the same idea at scale.

Next up: Serialization — turning objects into bytes (and back), with its serialVersionUID, transient fields, and security caveats.

Practice quiz

Continue this course

• Previous: The Builder Pattern
• Next: Serialization

Related lessons

• interfaces
• constructors
• lambdas