PrepKitBeta
LLD›SOLID Principles›Dependency Inversion Principle (DIP)

Dependency Inversion Principle (DIP)

SOLID Principles

Imagine a high-level OrderService responsible for processing customer orders. After successfully processing an order, it needs to send a notification to the customer. A direct approach would be to create and use a low-level EmailNotifier directly inside the service.

// Low-level detail
public class EmailNotifier {
    public void sendEmail(String toAddress, String subject, String message) {
        // Logic to connect to an SMTP server and send an email...
        System.out.println("Sending email notification...");
    }
}

// High-level policy
public class OrderService {
    // Direct, tight coupling to a low-level module
    private final EmailNotifier emailNotifier;

    public OrderService() {
        this.emailNotifier = new EmailNotifier(); // The problem is here!
    }

    public void processOrder(Order order) {
        // Core business logic for processing the order...
        System.out.println("Processing order " + order.getId());

        // After processing, send a notification
        emailNotifier.sendEmail(order.getCustomerEmail(), "Order Confirmation", "Your order is confirmed.");
    }
}

This design has two major flaws:

  1. Rigidity: What if the business decides to switch to SMS notifications? You must go into the OrderService and change its core logic, replacing EmailNotifier with SmsNotifier. The high-level policy is dictated by the low-level detail.
  2. Untestability: How do you write a unit test for processOrder? You can't test it without also instantiating an EmailNotifier and potentially sending a real email, which is slow, unreliable, and has external dependencies. The high-level module is not isolated.

The Principle: Inverting the Direction of Dependency

The Dependency Inversion Principle provides the solution. It is formally defined in two parts:

  1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
  2. Abstractions should not depend on details. Details should depend on abstractions.

The name "Dependency Inversion" can be confusing. It's about inverting the source code dependency direction.

  • Traditional Flow: [OrderService] ---> [EmailNotifier] (High-level depends on low-level)

  • Inverted Flow: [OrderService] ---> [INotifier] <--- [EmailNotifier] (High-level depends on an abstraction. Low-level also depends on that same abstraction.)

The dependency between OrderService and EmailNotifier has been "inverted" to flow towards the INotifier interface.

Using Dependency Injection

The most common way to implement DIP is through a pattern called Dependency Injection (DI). Instead of the class creating its own dependencies, they are "injected" from an external source.

Step 1: Define the Abstraction This abstraction is owned by the high-level layer, as it defines the contract that low-level modules must adhere to.

public interface INotifier {
    void sendNotification(String to, String subject, String message);
}

Step 2: The Detail Implements the Abstraction The low-level module now conforms to the contract defined by the abstraction.

public class EmailNotifier implements INotifier {
    @Override
    public void sendNotification(String to, String subject, String message) {
        // Logic to send an email...
        System.out.println("Sending email notification...");
    }
}

Step 3: Inject the Dependency into the High-level Module The OrderService no longer creates its own notifier. It asks for one in its constructor. This is called Constructor Injection.

public class OrderService {
    // Now depends on the abstraction, not the concrete detail
    private final INotifier notifier;

    // The dependency is "injected" from the outside.
    public OrderService(INotifier notifier) {
        this.notifier = notifier;
    }

    public void processOrder(Order order) {
        // ... Core business logic
        System.out.println("Processing order " + order.getId());

        // The service uses the injected dependency.
        notifier.sendNotification(order.getCustomerEmail(), "Order Confirmation", "Your order is confirmed.");
    }
}

The OrderService is now completely decoupled from the EmailNotifier.

Interview Focus: DIP vs. DI vs. IoC

This is a classic interview topic. It's critical to distinguish between these related, but different, concepts.

  • DIP (The Principle): This is the high-level design guideline. "Depend on abstractions."
  • Dependency Injection (DI) (The Pattern): This is a technique to achieve DIP. It's the act of providing a class with its dependencies from an outside source. Constructor Injection is the most common form of DI.
  • Inversion of Control (IoC) (The Paradigm): This is the broader concept where the control flow of a program is inverted. Instead of your code controlling the flow, you write components that are plugged into a framework, and the framework calls your code. DI is a form of IoC. When a framework automatically creates an EmailNotifier and "injects" it into your OrderService, it has taken control of object creation and dependency management.

How DIP Revolutionizes System Design

DIP is an important principle of SOLID that enables truly modern, modular architecture.

  • The Ultimate Decoupling Tool: DIP provides the strongest form of decoupling between modules. High-level business policies are no longer tainted by low-level implementation details like database choices or notification providers.

  • The Great Enabler of Testability: This is the most immediate, practical benefit of DIP. For our OrderService, we can now write a simple unit test by injecting a mock notifier, giving us complete control and isolation.

    // In a test file...
MockNotifier mockNotifier = new MockNotifier();
OrderService service = new OrderService(mockNotifier);
service.processOrder(someOrder);
mockNotifier.verifyCalledOnce(); // Assert that the notifier was used

  • The Foundation of Modern Frameworks: All major application frameworks (Spring, ASP.NET Core, Angular, NestJS) are built on DIP. They contain sophisticated "IoC Containers" that automatically manage the process of creating objects and injecting them wherever they are needed, allowing developers to focus purely on implementing business logic.

  • The Glue for Other SOLID Principles: DIP is what makes the other principles truly shine. You need to depend on abstractions (DIP) to allow for polymorphic extensions (OCP). This dependency on abstractions often leads you to create smaller, more focused interfaces (ISP).

Back to Course