DIP vs Dependency Injection — principle vs pattern

Direct Answer

DIP is a design principle about the direction and ownership of source dependencies. Dependency injection is a construction technique: an object receives a collaborator from outside. DI can help implement DIP, but it can inject a concrete class and therefore does not guarantee DIP. An IoC container such as Spring automates object creation and injection; manual constructor wiring is also DI.

Code Example

// Application policy declares the capability it needs.
interface PaymentGateway {
    void charge(Money amount);
}

final class OrderService {
    private final PaymentGateway gateway;

    // DI: the collaborator is supplied from outside.
    OrderService(PaymentGateway gateway) {
        this.gateway = gateway;
    }

    void checkout(Money total) {
        gateway.charge(total);
    }
}

final class StripeGateway implements PaymentGateway {
    public void charge(Money amount) { /* call Stripe SDK */ }
}

// Manual assembly; Spring could automate this construction.
OrderService service = new OrderService(new StripeGateway());

DI describes how gateway reaches OrderService. DIP describes why the service depends on the application PaymentGateway contract instead of the Stripe detail.

Common Mistakes & Pitfalls

• Calling DIP and DI synonyms: principle and construction technique differ.
• Saying DI is always how DIP is implemented: factories, service locators, and other wiring can still meet an abstraction, though they have trade-offs.
• Assuming an IoC container implies DIP: containers can inject concrete dependencies.
• Calling IoC only a DI tool: IoC also appears in callbacks and framework-controlled lifecycles.
• Avoiding all manual construction: a composition root must still select concrete implementations.