Inversion of Control & Dependency Injection

Notebook Summary

§ hand-copy · fast recall

Detailed Study Notes

You write a Car class. It has an engine, so you type new CombustionEngine() right inside the constructor and move on. It works. Then the product team wants an electric car. Now you're copying the class. Then the engine itself needs a camshaft and a crankshaft, each with their own parts, and your constructor becomes a tower of new calls that you have to keep in your head and rebuild every time you write a test. The lesson below is about one question: whose job is it to build an object's dependencies? The wrong answer — "the object itself" — is where most of this pain comes from.

1.1The problem: an object that builds its own parts

Start with the smallest possible failure. Here is a Car that has an Engine field but never sets it.

public interface Engine {
    void turnOn();
}

public class Car {
    private Engine engine;      // never assigned

    public Car() { }

    public void start() {
        engine.turnOn();        // engine is null here
    }
}

Car car = new Car();
car.start();                    // NullPointerException

The field engine is declared but nothing ever puts an object in it, so it holds null. Calling engine.turnOn() throws a NullPointerException. The obvious patch is to let the Car build its own engine:

public class CombustionEngine implements Engine {
    @Override
    public void turnOn() {
        System.out.println("Started combustion engine");
    }
}

public class Car {
    private Engine engine;

    public Car() {
        this.engine = new CombustionEngine();   // Car decides the engine
    }

    public void start() {
        engine.turnOn();
    }
}
// car.start()  ->  "Started combustion engine"

This runs. But the Car is now tightly coupled to CombustionEngine: the class definition hard-codes exactly which engine it uses. When an ElectricEngine arrives, your only tools are to write a second Car-like class or to edit this one. Both are bad — a class should not have to change every time a collaborator does.

1.2The tempting-but-wrong fix: a subclass per engine

The instinctive object-oriented move is to make Car abstract and subclass it once per engine type.

public abstract class Car {
    private Engine engine;
    public Car(Engine engine) { this.engine = engine; }
    public void start() { engine.turnOn(); }
}

public class CombustionCar extends Car {
    public CombustionCar() { super(new CombustionEngine()); }
}

public class ElectricCar extends Car {
    public ElectricCar() { super(new ElectricEngine()); }
}

Notice the Car constructor now accepts an Engine — that part is progress. But we've buried the new in a subclass. The drawback is written on the tin: a new Car subclass for every engine type. Ten engines, ten classes, all identical except for one super(...) line. The real fix is to stop hard-coding the choice anywhere in the hierarchy and let whoever creates the car decide the engine.

1.3Dependency Injection: hand the dependency in

Dependency Injection means an object receives its collaborators from outside instead of constructing them. Delete the subclasses. Keep one plain Car whose constructor takes an Engine, and let the caller pass whichever engine it wants.

public class Car {
    private Engine engine;
    public Car(Engine engine) {      // dependency arrives from outside
        this.engine = engine;
    }
    public void start() { engine.turnOn(); }
}

// the caller chooses the engine and injects it
Engine combustion = new CombustionEngine();
Car combustionCar = new Car(combustion);
combustionCar.start();               // "Started combustion engine"

Engine electric = new ElectricEngine();
Car electricCar = new Car(electric);
electricCar.start();                 // "Started electric engine"

One Car class now works with any engine, and it no longer knows or cares which concrete engine it got — only that the thing satisfies the Engine interface. This is inversion of control in miniature: the decision of which engine moved out of Car and up to the caller.

The slides call out the consequence: a runtime dependency. Before a Car can be instantiated, an Engine object must already exist to pass in. Dependencies are built first, then handed up the chain.

1.4Inversion of Control, named

Inversion of Control is the principle of handing object creation and wiring to a framework instead of doing it in your own code. "Inverted" because the normal flow — your code calls libraries and news up its own objects — is turned around: the framework creates your objects and calls into your code. You describe what you need; the container works out how to build and connect it.

DI is the most common way to achieve IoC, but the slides list the family so you recognize the alternatives in an interview:

• Template Method — a base class fixes the skeleton, subclasses fill in steps.
• Strategy — swap a behavior object at runtime.
• Contextualized Lookup — an object asks the container for what it needs.
• Service Locator — a central registry you query for dependencies.
• Dependency Injection — the container pushes dependencies in. This is what Spring uses.

1.5When dependencies have dependencies

Injection is easy with one engine. Real objects nest. A CombustionEngine needs a Camshaft and a Crankshaft, and those may need parts of their own.

public class Camshaft { }
public class Crankshaft { }

public class CombustionEngine implements Engine {
    private Camshaft camshaft;
    private Crankshaft crankshaft;

    public CombustionEngine(Camshaft camshaft, Crankshaft crankshaft) {
        this.camshaft = camshaft;
        this.crankshaft = crankshaft;
    }
    @Override public void turnOn() {
        System.out.println("Started combustion engine");
    }
}

To build one Car by hand you now have to construct the Camshaft and Crankshaft first, then the Engine, then the Car — in exactly that order, everywhere you need a car. This is the dependency tree, and doing it manually does not scale.

1.6The Spring Container (ApplicationContext)

The Spring Container is the object that reads your configuration, builds every declared object, wires their dependencies, and manages their lifecycle. Its common form is the ApplicationContext. You give it configuration — historically XML, now usually annotations or Java config — and it does the rest.

Two facts to memorize about what the container produces:

1.7The Spring Bean lifecycle

Because the container owns beans from birth to death, it defines a lifecycle — a common interview question. A bean is instantiated, its dependencies are injected, initialization callbacks run, it lives and serves requests, and finally destruction callbacks run before it's discarded.

1.8Configuration, part 1: explicit Java config

The first way to tell the container what to build is a Java configuration class: a class marked @Configuration whose @Bean methods each return one object for the container to manage.

@Configuration
public class AppConfig {

    @Bean
    public Camshaft camshaft() { return new Camshaft(); }

    @Bean
    public Crankshaft crankshaft() { return new Crankshaft(); }

    @Bean
    public Engine engine() {
        return new CombustionEngine(camshaft(), crankshaft());
    }

    @Bean
    public Car car() {
        return new Car(engine());
    }
}

• @Configuration — marks this class as a source of bean definitions.
• @Bean — declares that the method's return value should be registered as a dependency the container manages.

Explicit config is precise but verbose. With many classes, you're writing a @Bean method for each. That's the motivation for the second style.

1.9Configuration, part 2: component scanning

Instead of declaring every bean by hand, you can annotate the classes themselves and let Spring discover them by scanning the classpath.

@Component
public class CombustionEngine implements Engine {
    private final Camshaft camshaft;
    private final Crankshaft crankshaft;

    @Autowired                       // Spring supplies both here
    public CombustionEngine(Camshaft camshaft, Crankshaft crankshaft) {
        this.camshaft = camshaft;
        this.crankshaft = crankshaft;
    }
    @Override public void turnOn() {
        System.out.println("Started combustion engine");
    }
}

@Configuration
@ComponentScan("com.example.car")    // find @Components under this package
public class AppConfig { }

Now you declare where to look once, and every @Component in that package tree becomes a bean automatically. Two failure modes from the session are worth burning in:

1.10@Bean vs @Component

Both create beans; the difference is who declares them and whether you own the class. This is a classic interview comparison, so hold both columns in your head.

1.11Which type of injection to use

@Autowired can inject through a constructor, a setter, or directly onto a field. They are not equal.

Field injection reads as the shortest, so it's tempting. The session lists precisely why it's discouraged:

• Fields can't be final, so the dependency isn't immutable.
• It makes it too easy to pile on dependencies, quietly violating the single-responsibility principle.
• It couples the class tightly to the DI container — you can't construct it plainly in a test.
• Dependencies are hidden inside the class instead of visible in a constructor signature.

Interview & Practice Q&A

§ read the answer aloud

Key Takeaways

• A class that news its own dependencies is tightly coupled — brittle and hard to test.
• Dependency Injection supplies collaborators from outside; IoC is the principle of handing that job to a framework.
• Spring's ApplicationContext reads config, builds the dependency tree bottom-up, wires it, and manages each object's lifecycle.
• Container-managed objects are beans, singleton by default.
• Configure with @Bean (explicit, third-party-friendly) or @Component + @ComponentScan (auto-detected, for your own classes).
• Prefer constructor injection; a missing bean is NoSuchBeanDefinitionException; never autowire a static field.

Microexercises — Build the Muscle

You can recite "prefer constructor injection" and still freeze at a blank @Configuration class. These two drills close that gap. Attempt each before opening the walkthrough — write the refactor, predict the exception — then check yourself.

EX 1Break the solder: refactor tight coupling to constructor DI

public class CsvExporter {
    public void write(String data) { /* touches the disk */ }
}

public class ReportService {
    private final CsvExporter exporter = new CsvExporter();   // soldered in

    public void run(String data) {
        // ...build the report...
        exporter.write(data);
    }
}

public interface Exporter {
    void write(String data);
}

public class CsvExporter implements Exporter {
    public void write(String data) { /* touches the disk */ }
}

public class ReportService {
    private final Exporter exporter;

    public ReportService(Exporter exporter) {   // handed in from outside
        this.exporter = exporter;
    }

    public void run(String data) {
        exporter.write(data);
    }
}

@Configuration
public class AppConfig {

    @Bean
    public Exporter exporter() {
        return new CsvExporter();
    }

    @Bean
    public ReportService reportService(Exporter exporter) {   // Spring injects the bean above
        return new ReportService(exporter);
    }
}

@Component
public class CsvExporter implements Exporter { /* ... */ }

@Service   // a @Component with an intent-revealing name
public class ReportService {
    private final Exporter exporter;
    public ReportService(Exporter exporter) { this.exporter = exporter; }
    // ...
}

@Configuration
@ComponentScan("com.acme.reports")
public class AppConfig { }

var ctx = new AnnotationConfigApplicationContext(AppConfig.class);
ReportService svc = ctx.getBean(ReportService.class);
svc.run("...");

EX 2Diagnose a NoSuchBeanDefinitionException

NoSuchBeanDefinitionException: No qualifying bean of type
'com.fasterxml.jackson.databind.ObjectMapper' available

@Service
public class PricingService {
    private final ObjectMapper mapper;     // a third-party class (Jackson)
    public PricingService(ObjectMapper mapper) {
        this.mapper = mapper;
    }
}

@Configuration
@ComponentScan("com.shop.pricing")
public class AppConfig { }

@Configuration
@ComponentScan("com.shop.pricing")
public class AppConfig {

    @Bean
    public ObjectMapper objectMapper() {
        return new ObjectMapper();     // now it's a managed bean
    }
}