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.

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

💡 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.

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 .

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.

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.

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).

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 .

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

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary