All 15 Design Patterns in Java questions
More in Design Patterns in Java
What is the difference between composition and inheritance as ways to reuse code, and why does the design principle "favor composition over inheritance" generally guide modern Java design (including many design patterns themselves)? How would you implement the Composite pattern to treat individual objects and groups of objects uniformly, such as a file system with files and directories? How would you implement the Observer pattern in Java, and how does it compare to using the built-in PropertyChangeSupport or a reactive streams library? How would you implement the Decorator pattern in Java, and how does java.io's InputStream/OutputStream class hierarchy exemplify this pattern in the JDK itself? How would you implement the Visitor pattern in Java to add new operations to an existing class hierarchy without modifying those classes, and how do Java's sealed classes and pattern matching (switch expressions) provide a modern alternative? How would you use the Chain of Responsibility pattern to implement a request-processing pipeline (such as middleware-style validation/authentication/logging), and how does this relate conceptually to servlet filters or web framework middleware? How would you implement the Proxy pattern to add lazy initialization to an expensive-to-create object, and how does this differ structurally from the Decorator pattern despite both wrapping an object behind a shared interface?
Advertisement
Back to results for “Dependency Injection”
Java › Design Patterns in Java

How would you implement the Dependency Injection pattern manually (without a framework like Spring) using constructor injection, and what testability benefits does this provide?

Advanced

Answer

Manual constructor-based dependency injection means a class declares its dependencies as constructor parameters (rather than instantiating them directly inside the class or looking them up from a global registry/service locator), with the responsibility of actually providing those dependencies pushed to the caller (or, in a larger application, to a small "composition root" that wires everything together near the application's entry point) -- this decouples a class from concrete implementations of its dependencies, letting tests substitute mock/stub implementations trivially by passing them directly into the constructor, without needing any framework, reflection, or special test configuration.
public interface PaymentGateway { boolean charge(double amount); }

public class OrderService {
    private final PaymentGateway gateway;
    public OrderService(PaymentGateway gateway) {  // dependency injected via constructor
        this.gateway = gateway;
    }
    public boolean placeOrder(double total) { return gateway.charge(total); }
}

// In tests, trivially substitute a fake implementation, no framework needed
OrderService testService = new OrderService(amount -> true);  // lambda implementing PaymentGateway
Real-world example A unit test for OrderService constructs it directly with a hand-written fake PaymentGateway lambda that always returns true, testing OrderService's own logic in complete isolation from any real payment processing code or network calls, entirely without needing a DI framework or mocking library for this simple case.

Common follow-ups: What's the difference between constructor injection, setter injection, and field injection, and why is constructor injection generally preferred?;At what codebase size/complexity does manual DI wiring typically become unwieldy enough to justify adopting a framework like Spring?

Dependency Injection;Testing Strategy
All 15 Design Patterns in Java questions