Dependency Inversion Principle (DIP)

Lesson 5 of 5

Prerequisites

Dependency Inversion Principle (DIP)

What is it? (The Analogy)

Think about a light switch on your wall. You flip it up, the light turns on. You flip it down, the light turns off. Simple.

But here is the beautiful thing: the switch does not know or care WHAT it is controlling. It could be a regular incandescent bulb, an LED, a fluorescent tube, a smart bulb that changes colors, or even a ceiling fan wired to that switch. The switch depends on the concept of "something that can be toggled on and off" -- not on any specific device. And the bulb does not know what kind of switch controls it -- it could be a wall switch, a dimmer, a smart home app, or a clap-activated sensor.

Both the switch (high-level) and the bulb (low-level) depend on the same abstraction: the electrical interface (the wiring standard). Neither depends directly on the other.

That is the Dependency Inversion Principle: High-level modules should not depend on low-level modules. Both should depend on abstractions. And furthermore: Abstractions should not depend on details. Details should depend on abstractions.

This is sometimes called the Hollywood Principle: "Don not call us, we will call you." The high-level code says "I need something that can send messages" -- it does not say "I need Gmail specifically." The details (Gmail, Slack, SMS) plug into the abstraction, not the other way around.

Why do we need it?

Let us feel the pain. You are building a notification system for an online store:

java

1// BAD EXAMPLE -- High-level class directly depends on low-level classes
2public class OrderService {
3    // Directly creating low-level dependencies -- HARDCODED!
4    private MySQLDatabase database = new MySQLDatabase();
5    private GmailEmailSender emailSender = new GmailEmailSender();
6    private StripePaymentProcessor paymentProcessor = new StripePaymentProcessor();
7
8    public void placeOrder(Order order) {
9        // Validate order
10        if (order.getItems().isEmpty()) {
11            throw new IllegalArgumentException("Order cannot be empty!");
12        }
13
14        // Process payment -- locked to Stripe!
15        paymentProcessor.chargeCard(order.getTotal(), order.getCreditCard());
16
17        // Save to database -- locked to MySQL!
18        database.insertRow("orders", order.toMap());
19
20        // Send confirmation -- locked to Gmail!
21        emailSender.sendGmail(order.getCustomerEmail(),
22            "Order Confirmed",
23            "Your order #" + order.getId() + " has been placed!");
24    }
25}

What is wrong with this? Everything is hardwired:

java

// Want to switch from MySQL to PostgreSQL? Change OrderService.
// Want to switch from Gmail to SendGrid? Change OrderService.
// Want to switch from Stripe to PayPal? Change OrderService.
// Want to test without a real database/email/payment? IMPOSSIBLE!

The pain: Your high-level business logic (OrderService) is chained to specific low-level implementations. Changing any dependency means cracking open the core business class. Testing requires real databases and real email servers. The high-level module is a puppet controlled by low-level strings.

The Classic Violation -- Hardcoded Dependencies

Here is the core of the problem visualized:

java

1// WITHOUT DIP -- High depends on Low (bad!)
2
3// High-level: the important business logic
4public class NotificationManager {
5    // Directly depends on concrete class -- not an abstraction!
6    private SmtpEmailService emailService = new SmtpEmailService();
7
8    public void notifyUser(String userId, String message) {
9        String email = lookupEmail(userId);
10        emailService.sendSmtpEmail(email, message);  // Locked to SMTP!
11    }
12}

The problems multiply:

You cannot test NotificationManager without a real SMTP server
You cannot switch to push notifications or SMS without modifying this class
You cannot run this in a development environment without sending real emails
Every low-level change ripples up into high-level code

Warning: When you see new SomeConcreteClass() inside a high-level class, alarm bells should ring. That is a dependency being hardcoded. The high-level module is now permanently welded to that specific low-level implementation.

How to Fix It -- Step by Step

Identify the dependency direction -- Which classes are "high-level" (business logic, orchestration) and which are "low-level" (database, email, file system, APIs)?

Define an abstraction (interface) -- Create an interface that describes WHAT you need, not HOW it is done. MessageSender, not GmailSmtpClient.

Make both levels depend on the abstraction -- High-level code uses the interface. Low-level code implements the interface. Neither knows about the other.

Inject the dependency -- Instead of creating dependencies inside the class (new GmailSender()), pass them in through the constructor. This is called Constructor Injection.

Wire it together at the top -- In your main() method or configuration, decide which implementations to use and pass them in. This is where the "inversion" happens -- the decision flows from the top down.

Let us Build It Together

Let us build a Restaurant Order Notification System that can notify customers through different channels -- email, SMS, push notifications -- without the core logic knowing or caring which one.

java

1// ========================================
2// Step 1: Define the ABSTRACTION
3// What do we need? Something that sends messages.
4// We do NOT care how. That is the low-level detail.
5// ========================================
6
7// This is the contract. The "electrical interface" between
8// the switch and the bulb.
9public interface NotificationSender {
10    void send(String recipient, String subject, String message);
11    String getChannelName();  // For logging purposes
12}

java

1// ========================================
2// Step 2: Create LOW-LEVEL implementations
3// Each one knows HOW to send via its channel
4// Each one implements the same abstraction
5// ========================================
6
7// Email implementation
8public class EmailNotificationSender implements NotificationSender {
9    private String smtpServer;
10
11    public EmailNotificationSender(String smtpServer) {
12        this.smtpServer = smtpServer;
13    }
14
15    @Override
16    public void send(String recipient, String subject, String message) {
17        System.out.println("[EMAIL via " + smtpServer + "]");
18        System.out.println("  To: " + recipient);
19        System.out.println("  Subject: " + subject);
20        System.out.println("  Body: " + message);
21    }
22
23    @Override
24    public String getChannelName() {
25        return "Email";
26    }
27}

java

1// SMS implementation
2public class SmsNotificationSender implements NotificationSender {
3    private String apiKey;
4
5    public SmsNotificationSender(String apiKey) {
6        this.apiKey = apiKey;
7    }
8
9    @Override
10    public void send(String recipient, String subject, String message) {
11        // SMS does not really have "subjects", so we combine them
12        String smsText = subject + ": " + message;
13        System.out.println("[SMS via Twilio]");
14        System.out.println("  To: " + recipient);
15        System.out.println("  Text: " + smsText);
16    }
17
18    @Override
19    public String getChannelName() {
20        return "SMS";
21    }
22}

java

1// Push notification implementation
2public class PushNotificationSender implements NotificationSender {
3
4    @Override
5    public void send(String recipient, String subject, String message) {
6        System.out.println("[PUSH NOTIFICATION]");
7        System.out.println("  Device: " + recipient);
8        System.out.println("  Title: " + subject);
9        System.out.println("  Body: " + message);
10    }
11
12    @Override
13    public String getChannelName() {
14        return "Push Notification";
15    }
16}

java

1// ========================================
2// Step 3: Define abstraction for persistence too!
3// The restaurant should not care if orders go to
4// MySQL, MongoDB, or a text file
5// ========================================
6public interface OrderRepository {
7    void save(RestaurantOrder order);
8    RestaurantOrder findById(String orderId);
9    List<RestaurantOrder> findByCustomer(String customerId);
10}

java

1// One possible implementation -- MySQL
2public class MySqlOrderRepository implements OrderRepository {
3
4    @Override
5    public void save(RestaurantOrder order) {
6        System.out.println("[MySQL] Saving order #" + order.getId() + " to database...");
7    }
8
9    @Override
10    public RestaurantOrder findById(String orderId) {
11        System.out.println("[MySQL] Looking up order #" + orderId + "...");
12        return null; // Real implementation would query the database
13    }
14
15    @Override
16    public List<RestaurantOrder> findByCustomer(String customerId) {
17        System.out.println("[MySQL] Finding orders for customer: " + customerId);
18        return new ArrayList<>();
19    }
20}

java

1// Another implementation -- for testing! No real database needed!
2public class InMemoryOrderRepository implements OrderRepository {
3    private Map<String, RestaurantOrder> storage = new HashMap<>();
4
5    @Override
6    public void save(RestaurantOrder order) {
7        storage.put(order.getId(), order);
8        System.out.println("[IN-MEMORY] Saved order #" + order.getId());
9    }
10
11    @Override
12    public RestaurantOrder findById(String orderId) {
13        return storage.get(orderId);
14    }
15
16    @Override
17    public List<RestaurantOrder> findByCustomer(String customerId) {
18        return storage.values().stream()
19            .filter(o -> o.getCustomerId().equals(customerId))
20            .collect(Collectors.toList());
21    }
22}

java

1// ========================================
2// Step 4: The HIGH-LEVEL class depends
3// ONLY on abstractions -- never on details!
4// Dependencies are INJECTED through the constructor.
5// ========================================
6public class RestaurantOrderService {
7
8    // These are INTERFACES, not concrete classes!
9    private final OrderRepository orderRepo;
10    private final NotificationSender notificationSender;
11
12    // CONSTRUCTOR INJECTION -- dependencies come from outside
13    // The class does not create its own dependencies!
14    public RestaurantOrderService(OrderRepository orderRepo,
15                                   NotificationSender notificationSender) {
16        this.orderRepo = orderRepo;
17        this.notificationSender = notificationSender;
18    }
19
20    public void placeOrder(RestaurantOrder order) {
21        // Business logic -- this is the important stuff
22        System.out.println("\n=== Placing Order #" + order.getId() + " ===");
23
24        // Validate the order
25        if (order.getItems().isEmpty()) {
26            throw new IllegalArgumentException("Cannot place an empty order!");
27        }
28
29        // Save the order -- we do not know or care if this is MySQL, Mongo, or a test stub
30        orderRepo.save(order);
31
32        // Notify the customer -- we do not know if this is email, SMS, or push
33        notificationSender.send(
34            order.getCustomerContact(),
35            "Order Confirmed!",
36            "Your order #" + order.getId() + " for " + order.getItems().size()
37                + " items is being prepared. Estimated time: 30 minutes."
38        );
39
40        System.out.println("Order placed successfully via " + notificationSender.getChannelName() + "!");
41    }
42
43    public void cancelOrder(String orderId) {
44        RestaurantOrder order = orderRepo.findById(orderId);
45        if (order == null) {
46            System.out.println("Order not found: " + orderId);
47            return;
48        }
49
50        System.out.println("\n=== Cancelling Order #" + orderId + " ===");
51        notificationSender.send(
52            order.getCustomerContact(),
53            "Order Cancelled",
54            "Your order #" + orderId + " has been cancelled. Refund incoming."
55        );
56    }
57}

java

1// ========================================
2// Step 5: Wire it all together in main()
3// THIS is where you decide which implementations to use
4// ========================================
5public class RestaurantApp {
6    public static void main(String[] args) {
7
8        // --- PRODUCTION configuration ---
9        // Choose real implementations:
10        OrderRepository prodRepo = new MySqlOrderRepository();
11        NotificationSender prodNotifier = new EmailNotificationSender("smtp.gmail.com");
12
13        RestaurantOrderService prodService = new RestaurantOrderService(prodRepo, prodNotifier);
14
15        // Create and place an order
16        RestaurantOrder order = new RestaurantOrder("ORD-001", "CUST-42", "+1234567890");
17        order.addItem("Margherita Pizza");
18        order.addItem("Garlic Bread");
19        order.addItem("Tiramisu");
20
21        prodService.placeOrder(order);  // Uses MySQL + Email
22
23        System.out.println("\n====================================");
24        System.out.println("  Now let us switch EVERYTHING...");
25        System.out.println("====================================");
26
27        // --- TESTING configuration ---
28        // Switch to test implementations -- NO CODE CHANGES in OrderService!
29        OrderRepository testRepo = new InMemoryOrderRepository();
30        NotificationSender testNotifier = new SmsNotificationSender("test-api-key");
31
32        RestaurantOrderService testService = new RestaurantOrderService(testRepo, testNotifier);
33
34        // Same business logic, completely different infrastructure!
35        RestaurantOrder testOrder = new RestaurantOrder("ORD-TEST", "CUST-99", "555-0123");
36        testOrder.addItem("Test Burger");
37
38        testService.placeOrder(testOrder);  // Uses InMemory + SMS
39
40        // Want push notifications instead? Just swap the sender:
41        NotificationSender pushNotifier = new PushNotificationSender();
42        RestaurantOrderService pushService = new RestaurantOrderService(testRepo, pushNotifier);
43
44        RestaurantOrder pushOrder = new RestaurantOrder("ORD-PUSH", "CUST-77", "device-token-abc");
45        pushOrder.addItem("Sushi Platter");
46        pushService.placeOrder(pushOrder);  // Uses InMemory + Push
47    }
48}

Aha moment: Notice how RestaurantOrderService was written ONCE and never changed, yet it works with MySQL, in-memory storage, email, SMS, AND push notifications. The business logic is completely decoupled from infrastructure details. Want to switch to MongoDB next month? Write a MongoOrderRepository that implements OrderRepository and pass it in. Zero changes to RestaurantOrderService.

Visual Mental Model

java

1  BEFORE (Direct Dependency):            AFTER (Inverted Dependency):
2
3  +------------------+                   +------------------+
4  |  OrderService    |                   |  OrderService    |
5  |  (high-level)    |                   |  (high-level)    |
6  +------------------+                   +------------------+
7     |       |       |                          |         |
8     |       |       |                          v         v
9     v       v       v                  +-----------+ +--------+
10  +------+ +-----+ +------+            | <<interface| |<<inter-|
11  |MySQL | |Gmail| |Stripe|            | OrderRepo>>| |face>>  |
12  +------+ +-----+ +------+            +-----------+ |Notifi- |
13                                          |    |      |cation  |
14  High-level DEPENDS on low-level!        v    v      |Sender>>|
15  Change MySQL = change OrderService      |    |      +--------+
16                                       +----+ +------+ |    |
17                                       |MySQL| |Mongo | v    v
18                                       +----+ +------++----++---+
19                                                       |Email||SMS|
20                                       Both levels depend  +----++---+
21                                       on ABSTRACTIONS!

Why This Is the Foundation of Testable Code

DIP is what makes unit testing possible. Without it, testing OrderService requires a running MySQL database, a working SMTP server, and a Stripe account with test credentials. That is not a unit test -- that is an integration test nightmare.

With DIP, you can inject mock or fake implementations:

java

1// In your test file:
2@Test
3public void testPlaceOrder_sendsNotification() {
4    // Create a fake repository -- no database needed!
5    InMemoryOrderRepository fakeRepo = new InMemoryOrderRepository();
6
7    // Create a fake notifier that just records what was sent
8    FakeNotificationSender fakeNotifier = new FakeNotificationSender();
9
10    // Inject fakes into the service
11    RestaurantOrderService service = new RestaurantOrderService(fakeRepo, fakeNotifier);
12
13    // Run the business logic
14    RestaurantOrder order = new RestaurantOrder("ORD-1", "CUST-1", "test@test.com");
15    order.addItem("Pizza");
16    service.placeOrder(order);
17
18    // Verify the behavior -- did it send the right notification?
19    assertEquals("Order Confirmed!", fakeNotifier.getLastSubject());
20    assertEquals("test@test.com", fakeNotifier.getLastRecipient());
21}

Without DIP, this test would need real infrastructure. With DIP, it runs in milliseconds with zero external dependencies.

How This Connects to Design Patterns

DIP is the philosophical foundation of some of the most important design patterns:

The Factory Pattern is a natural companion to DIP. Instead of using new MySqlRepo() directly, a factory decides which implementation to create. The high-level code asks the factory for an OrderRepository and gets whatever the factory decides to give it -- MySQL in production, InMemory in tests.

The Strategy Pattern is DIP in action. When you inject different NotificationSender implementations, each one is a "strategy" for sending notifications. The high-level code does not know which strategy it is using -- it just knows the interface.

Dependency Injection frameworks like Spring, Guice, and Dagger are essentially tools that automate the "wire it together" step. Instead of manually writing new RestaurantOrderService(new MySqlRepo(), new EmailSender()), the framework reads a configuration and does the wiring for you. But the PRINCIPLE is the same -- high-level depends on abstractions, implementations are injected.

Common Mistakes and Gotchas

Creating abstractions for EVERYTHING -- Not every class needs an interface. If you have a StringUtils class with pure functions, it does not need a StringUtilsInterface. Use DIP for things that genuinely VARY: databases, external services, notification channels.
Leaky abstractions -- If your interface is named MySqlOrderRepository or has methods like executeSqlQuery(), the abstraction is leaking implementation details. Name it OrderRepository with methods like save() and findById().
Injecting too many dependencies -- If your constructor takes 8+ parameters, the class probably has too many responsibilities (SRP violation!). DIP does not fix bad class design -- it exposes it.
Confusing DIP with Dependency Injection -- DIP is a PRINCIPLE (depend on abstractions). Dependency Injection is a TECHNIQUE (pass dependencies through constructors). You can follow DIP without a DI framework, and you can use a DI framework without following DIP.
Forgetting to invert -- If your interface is defined in the low-level module (inside the database package), the dependency is not truly inverted. The interface should be defined where the HIGH-LEVEL module is, or in a shared module.
Constructor injection vs field injection -- Prefer constructor injection. Field injection (using @Autowired on private fields) hides dependencies and makes testing harder. Constructor injection makes dependencies explicit and impossible to forget.

Interview Tip

When an interviewer asks "How would you make this testable?" or "How would you handle switching databases?" -- DIP is your answer. Say: "I would define an interface for the dependency, have the class accept it through constructor injection, and provide the concrete implementation from outside. This way, we can swap MySQL for an in-memory store in tests, or switch to PostgreSQL in production without touching the business logic." Then sketch the before/after on the whiteboard showing the dependency arrows INVERTING -- from pointing down (high to low) to both pointing at the interface in the middle. That visual is incredibly powerful in interviews.

Quick Quiz

Your ReportGenerator class directly creates a PdfWriter object inside its constructor. How does this violate DIP, and how would you fix it?

What is the difference between Dependency Inversion (the principle) and Dependency Injection (the technique)? Can you have one without the other?

You are building a weather app that fetches data from OpenWeatherMap API. How would you apply DIP so that your app is not locked to this one weather provider and can be easily tested without making real API calls?

Summary -- Key Takeaways

High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces). This is the "inversion" -- the dependency arrows point toward abstractions instead of toward implementations.
Use Constructor Injection to pass dependencies from outside. Never let a high-level class create its own low-level dependencies with new.
DIP is the foundation of testable code. When you can inject a fake database or a mock email sender, unit testing becomes fast, reliable, and independent of infrastructure.
DIP enables the Strategy, Factory, and Observer patterns and is the principle behind Dependency Injection frameworks like Spring. Master DIP and half of design patterns will click into place.

Interface Segregation Principle (ISP)Previous

Home