Dependency Inversion Principle

Description

The Dependency Inversion Principle says business rules shouldn't depend on databases, email servers, clocks or other details - both should depend on an abstraction that the business code owns. It's what makes core logic testable in milliseconds and lets infrastructure change without touching it. This skill covers the principle, dependency injection as the usual way to apply it, and how to avoid wrapping everything in interfaces.

Here's the kind of code it's about:

class OrderService {
    private final MySqlOrderDao dao = new MySqlOrderDao();       // concrete database
    private final SmtpMailer mailer = new SmtpMailer("smtp.acme.com");  // concrete email server

    void placeOrder(Order order) {
        dao.insert(order);
        mailer.send(order.customerEmail(), "Thanks for your order!");
    }
}

class OrderService:
    def __init__(self):
        self._dao = MySqlOrderDao()                          # concrete database
        self._mailer = SmtpMailer("smtp.acme.com")           # concrete email server

    def place_order(self, order: Order) -> None:
        self._dao.insert(order)
        self._mailer.send(order.customer_email, "Thanks for your order!")

The most important code in the system - the business rule "place an order" - is welded to MySQL and one SMTP server. You can't test it without a database and a mail server, and switching to Postgres or an email API means editing OrderService.

We'll go from simple to more technical:

1. The principle: abstractions owned by the high-level code.
2. Applying it with constructor injection, step by step.
3. Where you'll see it: DI containers, JDBC and DB-API, ports and adapters.
4. When an interface isn't worth it, and how abstractions leak.

The principle

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

The high-level code declares what it needs as an interface it owns; the details implement it; something outside wires them together.

interface OrderRepository { void save(Order order); }
interface Notifier { void notify(String to, String message); }

class OrderService {
    private final OrderRepository orders;
    private final Notifier notifier;

    OrderService(OrderRepository orders, Notifier notifier) {   // details are injected
        this.orders = orders;
        this.notifier = notifier;
    }

    void placeOrder(Order order) {
        orders.save(order);
        notifier.notify(order.customerEmail(), "Thanks for your order!");
    }
}

// Production: new OrderService(new PostgresOrderRepository(ds), new EmailApiNotifier(key));
// Tests:      new OrderService(new InMemoryOrderRepository(), new RecordingNotifier());

from typing import Protocol


class OrderRepository(Protocol):
    def save(self, order: Order) -> None: ...


class Notifier(Protocol):
    def notify(self, to: str, message: str) -> None: ...


class OrderService:
    def __init__(self, orders: OrderRepository, notifier: Notifier):   # details are injected
        self._orders = orders
        self._notifier = notifier

    def place_order(self, order: Order) -> None:
        self._orders.save(order)
        self._notifier.notify(order.customer_email, "Thanks for your order!")


# Production: OrderService(PostgresOrderRepository(pool), EmailApiNotifier(key))
# Tests:      OrderService(InMemoryOrderRepository(), RecordingNotifier())

How to apply it, step by step

1. Identify the policy (business rules) and the details (databases, HTTP clients, clocks, file systems).
2. Let the policy define small interfaces describing what it needs - in its own terms.
3. Make the details implement those interfaces.
4. Pass the details in through the constructor (dependency injection), instead of creating them inside.
5. Wire everything in one place at startup - by hand or with a framework like Spring.

Where you'll see it

• Spring and other DI containers exist to do step 5 for you: constructor parameters typed as interfaces, implementations chosen by configuration. Python projects mostly wire by hand in one startup function (FastAPI's Depends is the web-framework version).
• JDBC: your code talks to java.sql.Connection; each database vendor ships a driver that implements it. (Python's equivalent is the DB-API, PEP 249: psycopg, sqlite3 and mysqlclient all offer the same connect(), cursor() and execute().)
• Hexagonal / ports-and-adapters architecture: the domain defines ports (interfaces), infrastructure provides adapters.

Which tool for which job?

Common mistakes

Check yourself

Try to answer before opening each one - recalling beats re-reading.

1. Why is new SmtpMailer() inside OrderService a DIP violation, and what's the fix?

2. How does DIP make code with timeouts or expiry dates easier to test?

3. Who should own the interface - the database layer or the business logic?

Key takeaways

• Business rules depend on abstractions they own; details implement them.
• Inject dependencies through constructors; wire them in one place.
• Clocks, databases, HTTP clients and file systems are all details worth abstracting.
• Don't wrap stable, dependency-free code in interfaces just because.