SOLID Principle · DIP

Dependency Inversion Principle

High-level modules and low-level modules should both depend on abstractions.

Dependency Inversion Principle (DIP): A Complete Guide with Examples in 11 Programming Languages

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules — both should depend on abstractions. Furthermore, abstractions should not depend on details; details should depend on abstractions. In practice, this means the code that embodies your business logic should never be coupled directly to the code that talks to a database, sends emails, or makes HTTP calls. The business logic defines what it needs through an abstraction; the infrastructure details implement that abstraction. The flow of control runs top-down, but the flow of dependencies runs toward the abstraction — inverted from the naive approach.

In this comprehensive guide, we'll explore DIP with real-world examples in Python, TypeScript, Java, JavaScript, C#, PHP, Go, Rust, Dart, Swift, and Kotlin — complete with language-specific best practices, common violations, and clear guidance on when and how to apply this foundational principle.

Table of Contents

What is the Dependency Inversion Principle?

DIP is the fifth and final SOLID principle, introduced by Robert C. Martin. Its two-part definition is precise:

  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.

Consider a classic violation: a UserService (high-level) that directly instantiates a MySQLUserRepository (low-level) inside its constructor. The service is coupled to MySQL. To test the service, you need a real MySQL database. To switch to PostgreSQL, you rewrite the service. To test in isolation, you can't — the database is hard-wired in.

DIP solves this by inverting who owns the dependency. Instead of UserService instantiating MySQLUserRepository, you define a UserRepository interface. UserService depends on UserRepository (the abstraction). MySQLUserRepository implements UserRepository (the detail depends on the abstraction). The concrete database class is injected into the service from outside — at the composition root, a DI container, or application startup.

The inversion is this: in the naive design, high-level code imports and creates low-level code. In the DIP design, low-level code implements abstractions that high-level code declares. The direction of the source-code dependency is reversed from the direction of control flow. High-level modules are now independent of any specific infrastructure — they can be tested, reused, and deployed without the details they once controlled.

Why Follow DIP?

DIP provides several critical benefits:

  1. Testability: High-level business logic can be tested with fast, in-memory fakes — no real database, no live email server, no network calls required. Tests run in milliseconds.
  2. Flexibility: Swap infrastructure implementations (MySQL → PostgreSQL, SendGrid → SES, Redis → in-memory cache) by changing what is injected — the business logic never changes.
  3. Parallel Development: Infrastructure teams and business logic teams work on independent components. The abstraction is the contract; both sides implement against it independently.
  4. Reuse: Business logic modules that depend only on abstractions can be reused in any context that provides compatible implementations — web apps, CLI tools, background workers.
  5. Isolation: A bug in the database layer cannot silently corrupt the business logic layer — they are separated by an abstraction boundary.
  6. Open/Closed Compliance: DIP enables OCP. A business module that depends only on abstractions is open for extension (new implementations) and closed for modification (the business logic never changes to accommodate a new database).

DIP Comparison

Let's compare DIP-compliant and DIP-violating designs across key dimensions:

DimensionDIP ViolationDIP Compliant
Dependency directionHigh-level imports and creates low-levelBoth depend on an abstraction; details injected from outside
Unit test setupRequires real infrastructure (DB, SMTP, network)Tests inject fast in-memory fakes — millisecond execution
Swapping infrastructureRequires editing business logicChange what is injected at the composition root
CouplingBusiness logic coupled to one specific infrastructureBusiness logic coupled to an abstraction it defines
Parallel developmentInfrastructure must exist before business logic can runBoth sides developed independently against the shared interface
ReuseBusiness module carries infrastructure dependencyBusiness module works in any context with any compatible implementation

Key Distinctions:

  • DIP vs. Dependency Injection (DI): DI is one mechanism to achieve DIP — passing dependencies through the constructor rather than instantiating them inside. DIP is the principle; DI is one technique for implementing it. You can also use service locators, factory functions, or module-level configuration to achieve DIP.
  • DIP vs. IoC (Inversion of Control): IoC is the broad concept of inverting who controls which code runs. DIP is a specific principle about inverting the direction of source-code dependencies. IoC containers (Spring, ASP.NET Core DI, Dagger) are tools that automate DI to implement DIP at scale.
  • DIP vs. OCP: OCP says don't modify existing code to accommodate new variants. DIP creates the abstraction boundary that makes OCP possible. Without DIP, the business logic is so tightly coupled to infrastructure that extensions require modifications. With DIP, new infrastructure implementations arrive without touching the business layer.

DIP Explained

The Direction of Dependencies

In the naive layered architecture, dependencies flow top-to-bottom: the UI depends on the service, the service depends on the repository, the repository depends on the database driver.

UI → UserService → MySQLRepository → MySQL Driver

The problem: UserService cannot exist without MySQLRepository. Change MySQL and you must change the service. Test the service and you must spin up MySQL.

DIP inverts the dependency at the boundary between high-level and low-level:

UI → UserService → [UserRepository interface] ← MySQLRepository → MySQL Driver

Now UserService depends on UserRepository (an abstraction it controls). MySQLRepository depends on the same interface — it implements it. The arrow from MySQLRepository to the interface points upward (toward the high-level module), not downward. The dependency is inverted.

Who Owns the Abstraction?

A key subtlety: the abstraction should be defined in the same layer as the high-level module that uses it, not in the layer of the module that implements it. UserRepository belongs with UserService, not with MySQLUserRepository. This ensures that the high-level module is independent — it never needs to import from the low-level layer.

The Composition Root

With DIP, someone must assemble the concrete implementations and inject them. That place is the composition root — the application entry point (main function, app startup, DI container configuration). The composition root is the only place where concrete classes are instantiated. Everything else works with abstractions.

Composition Root:
  repo    = new MySQLUserRepository(connection)
  service = new UserService(repo)
  handler = new UserController(service)

The composition root knows about everything. Everything else knows only about its immediate abstraction. This is the architecture that DIP enables.

Three Ways to Inject Dependencies

  1. Constructor Injection (preferred): Dependencies are passed via the constructor. The class declares what it needs; the composition root provides it. Immutable, explicit, and testable.
  2. Method/Parameter Injection: The dependency is passed to the method that needs it. Good for optional or per-call dependencies.
  3. Property/Setter Injection: The dependency is set via a property or setter after construction. Useful when circular dependencies exist, but generally less preferable than constructor injection.

Class Diagram

Here's the UML class diagram showing DIP applied to a notification system:

Beginner-Friendly Example

Let's illustrate DIP with the most common real-world case: a service that reads and writes data. We start with the violation — a service that directly creates its own infrastructure — then refactor to full DIP compliance.

from __future__ import annotations
from abc import ABC, abstractmethod
from dataclasses import dataclass


# ── ❌ DIP VIOLATION ───────────────────────────────────────────────
# UserService directly depends on MySQLUserRepository — a concrete detail.
# To test UserService, you need a real MySQL database.
# To swap to PostgreSQL, you must edit UserService.

class MySQLUserRepositoryBad:
    """Low-level detail: talks directly to MySQL."""
    def find(self, user_id: int) -> dict:
        print(f"  [MySQL] SELECT * FROM users WHERE id={user_id}")
        return {"id": user_id, "name": "Alice", "email": "alice@example.com"}

    def save(self, user: dict) -> None:
        print(f"  [MySQL] INSERT INTO users VALUES ({user})")


class BadUserService:
    """High-level module — but directly creates the low-level detail.
    Testing this class requires a live database. Swapping MySQL requires editing this class."""

    def __init__(self) -> None:
        self._repo = MySQLUserRepositoryBad()  # Hard-wired dependency — DIP violation

    def get_user(self, user_id: int) -> dict:
        return self._repo.find(user_id)

    def register(self, name: str, email: str) -> None:
        self._repo.save({"name": name, "email": email})


# ── ✅ DIP COMPLIANT ───────────────────────────────────────────────

# Step 1: Define the abstraction in the high-level layer.
# UserService owns this interface — it declares what it needs.
class UserRepository(ABC):
    """Abstraction owned by the high-level layer.
    Low-level implementations depend on this; it does not depend on them."""

    @abstractmethod
    def find(self, user_id: int) -> "User": ...

    @abstractmethod
    def save(self, user: "User") -> None: ...


@dataclass
class User:
    id:    int
    name:  str
    email: str


# Step 2: High-level module depends only on the abstraction.
class UserService:
    """Business logic — depends only on UserRepository (abstraction).
    Works with any implementation: MySQL, PostgreSQL, in-memory, mock."""

    def __init__(self, repository: UserRepository) -> None:
        self._repo = repository  # Injected — never created internally

    def get_user(self, user_id: int) -> User:
        user = self._repo.find(user_id)
        print(f"  [Service] Found user: {user.name}")
        return user

    def register(self, name: str, email: str) -> User:
        user = User(id=0, name=name, email=email)
        self._repo.save(user)
        print(f"  [Service] Registered: {name}")
        return user


# Step 3: Low-level details implement the abstraction.
class MySQLUserRepository(UserRepository):
    """Detail — implements the abstraction. Depends on the abstraction, not the other way around."""

    def find(self, user_id: int) -> User:
        print(f"  [MySQL] SELECT * FROM users WHERE id={user_id}")
        return User(id=user_id, name="Alice", email="alice@example.com")

    def save(self, user: User) -> None:
        print(f"  [MySQL] INSERT INTO users VALUES ('{user.name}', '{user.email}')")


class PostgreSQLUserRepository(UserRepository):
    """Swap implementation — no changes to UserService required."""

    def find(self, user_id: int) -> User:
        print(f"  [PostgreSQL] SELECT * FROM users WHERE id={user_id}")
        return User(id=user_id, name="Alice", email="alice@example.com")

    def save(self, user: User) -> None:
        print(f"  [PostgreSQL] INSERT INTO users VALUES ('{user.name}', '{user.email}')")


class InMemoryUserRepository(UserRepository):
    """Fast test double — no database needed. Used in unit tests."""

    def __init__(self) -> None:
        self._store: dict[int, User] = {}
        self._next_id = 1

    def find(self, user_id: int) -> User:
        if user_id not in self._store:
            raise KeyError(f"User {user_id} not found")
        return self._store[user_id]

    def save(self, user: User) -> None:
        user.id = self._next_id
        self._store[self._next_id] = user
        self._next_id += 1


# ── Composition Root ───────────────────────────────────────────────
# The only place that knows about concrete classes.
# Everything else works through abstractions.
if __name__ == "__main__":
    print("=== DIP Compliant User Service ===\n")

    # Production: inject MySQL
    print("--- Production (MySQL) ---")
    mysql_service = UserService(repository=MySQLUserRepository())
    mysql_service.get_user(1)
    mysql_service.register("Bob", "bob@example.com")

    print()

    # Development: inject PostgreSQL — UserService unchanged
    print("--- Development (PostgreSQL) ---")
    pg_service = UserService(repository=PostgreSQLUserRepository())
    pg_service.get_user(1)

    print()

    # Testing: inject in-memory — no real database needed
    print("--- Testing (In-Memory) ---")
    repo = InMemoryUserRepository()
    test_service = UserService(repository=repo)
    test_service.register("Alice", "alice@test.com")
    user = test_service.get_user(1)
    assert user.name == "Alice"
    print(f"  ✅ Test passed: user.name == '{user.name}'")

Production-Ready Example

Now let's build a complete order processing system — a real-world scenario with multiple infrastructure dependencies: a repository for persistence, a notifier for confirmations, a payment gateway for charging, and a logger for auditing. Without DIP, the order service would be glued to MySQL, SendGrid, Stripe, and a file logger. With DIP, the service knows only its abstractions — every implementation is swappable and independently testable.

🐍 Python

from __future__ import annotations
from abc import ABC, abstractmethod
from dataclasses import dataclass, field
from datetime import datetime
from typing import Optional
import uuid


# ── Domain Models ───────────────────────────────────────────────────
@dataclass
class OrderItem:
    product_id: str
    name:       str
    price:      float
    quantity:   int


@dataclass
class Order:
    id:         str = field(default_factory=lambda: str(uuid.uuid4())[:8])
    customer:   str = ""
    email:      str = ""
    items:      list[OrderItem] = field(default_factory=list)
    total:      float = 0.0
    status:     str = "pending"
    created_at: datetime = field(default_factory=datetime.now)

    def calculate_total(self) -> float:
        self.total = sum(item.price * item.quantity for item in self.items)
        return self.total


# ── Abstractions (owned by the high-level business layer) ──────────
class OrderRepository(ABC):
    """Persistence abstraction. Business logic never knows if this is MySQL or Mongo."""
    @abstractmethod
    def save(self, order: Order) -> None: ...

    @abstractmethod
    def find_by_id(self, order_id: str) -> Optional[Order]: ...

    @abstractmethod
    def find_by_customer(self, email: str) -> list[Order]: ...


class PaymentGateway(ABC):
    """Payment abstraction. Business logic never knows if this is Stripe or PayPal."""
    @abstractmethod
    def charge(self, amount: float, customer_email: str, order_id: str) -> bool: ...


class OrderNotifier(ABC):
    """Notification abstraction. Business logic never knows if this is email or SMS."""
    @abstractmethod
    def notify_order_placed(self, order: Order) -> None: ...

    @abstractmethod
    def notify_payment_failed(self, order: Order) -> None: ...


class AuditLogger(ABC):
    """Logging abstraction. Business logic never knows if this is file, Datadog, or CloudWatch."""
    @abstractmethod
    def log(self, event: str, context: dict) -> None: ...


# ── High-Level Business Logic ───────────────────────────────────────
class OrderService:
    """
    Core business logic — depends only on abstractions.
    Testable with in-memory fakes. No infrastructure details anywhere.
    """

    def __init__(
        self,
        repository: OrderRepository,
        payment:    PaymentGateway,
        notifier:   OrderNotifier,
        logger:     AuditLogger,
    ) -> None:
        self._repo     = repository
        self._payment  = payment
        self._notifier = notifier
        self._logger   = logger

    def place_order(self, customer: str, email: str, items: list[OrderItem]) -> Order:
        order = Order(customer=customer, email=email, items=items)
        order.calculate_total()

        self._logger.log("order.placing", {"customer": customer, "total": order.total})

        charged = self._payment.charge(
            amount=order.total, customer_email=email, order_id=order.id,
        )

        if not charged:
            order.status = "payment_failed"
            self._repo.save(order)
            self._notifier.notify_payment_failed(order)
            self._logger.log("order.payment_failed", {"order_id": order.id})
            raise RuntimeError(f"Payment failed for order {order.id}")

        order.status = "confirmed"
        self._repo.save(order)
        self._notifier.notify_order_placed(order)
        self._logger.log("order.placed", {"order_id": order.id, "total": order.total})

        return order

    def get_order(self, order_id: str) -> Optional[Order]:
        return self._repo.find_by_id(order_id)


# ── Infrastructure Implementations ─────────────────────────────────

class InMemoryOrderRepository(OrderRepository):
    def __init__(self) -> None:
        self._store: dict[str, Order] = {}

    def save(self, order: Order) -> None:
        self._store[order.id] = order

    def find_by_id(self, order_id: str) -> Optional[Order]:
        return self._store.get(order_id)

    def find_by_customer(self, email: str) -> list[Order]:
        return [o for o in self._store.values() if o.email == email]


class StripePaymentGateway(PaymentGateway):
    def charge(self, amount: float, customer_email: str, order_id: str) -> bool:
        print(f"  [Stripe] Charging ${amount:.2f} to {customer_email} for order {order_id}")
        return True


class EmailOrderNotifier(OrderNotifier):
    def __init__(self, smtp_host: str) -> None:
        self._smtp_host = smtp_host

    def notify_order_placed(self, order: Order) -> None:
        print(f"  [Email] → {order.email}: Order {order.id} confirmed! Total: ${order.total:.2f}")

    def notify_payment_failed(self, order: Order) -> None:
        print(f"  [Email] → {order.email}: Payment failed for order {order.id}")


class ConsoleAuditLogger(AuditLogger):
    def log(self, event: str, context: dict) -> None:
        print(f"  [AUDIT] {event}: {context}")


# ── Test Doubles ────────────────────────────────────────────────────

class AlwaysSucceedPaymentGateway(PaymentGateway):
    def charge(self, amount: float, customer_email: str, order_id: str) -> bool:
        return True  # No Stripe account needed in tests


class AlwaysFailPaymentGateway(PaymentGateway):
    def charge(self, amount: float, customer_email: str, order_id: str) -> bool:
        return False


class SilentNotifier(OrderNotifier):
    def __init__(self) -> None:
        self.placed_orders:  list[Order] = []
        self.failed_orders:  list[Order] = []

    def notify_order_placed(self, order: Order) -> None:
        self.placed_orders.append(order)

    def notify_payment_failed(self, order: Order) -> None:
        self.failed_orders.append(order)


class NoOpLogger(AuditLogger):
    def log(self, event: str, context: dict) -> None:
        pass


# ── Composition Root ───────────────────────────────────────────────
if __name__ == "__main__":
    print("=== Order Processing System (DIP Compliant) ===\n")

    print("--- Production ---")
    prod_service = OrderService(
        repository=InMemoryOrderRepository(),
        payment=StripePaymentGateway(),
        notifier=EmailOrderNotifier("smtp.company.com"),
        logger=ConsoleAuditLogger(),
    )

    order = prod_service.place_order(
        customer="Alice",
        email="alice@example.com",
        items=[
            OrderItem("SKU-001", "Laptop Stand",   49.99, 1),
            OrderItem("SKU-002", "USB-C Hub",       29.99, 2),
        ],
    )
    print(f"\n  ✅ Order placed: {order.id} | Status: {order.status} | Total: ${order.total:.2f}")

    print("\n\n--- Unit Tests (No Infrastructure) ---")
    notifier     = SilentNotifier()
    test_service = OrderService(
        repository=InMemoryOrderRepository(),
        payment=AlwaysSucceedPaymentGateway(),
        notifier=notifier,
        logger=NoOpLogger(),
    )

    test_order = test_service.place_order(
        customer="Test User",
        email="test@test.com",
        items=[OrderItem("SKU-001", "Widget", 10.00, 3)],
    )
    assert test_order.status == "confirmed"
    assert len(notifier.placed_orders) == 1
    assert test_order.total == 30.00
    print(f"  ✅ Test 1 passed: order confirmed, notified, total=${test_order.total:.2f}")

    fail_service = OrderService(
        repository=InMemoryOrderRepository(),
        payment=AlwaysFailPaymentGateway(),
        notifier=notifier,
        logger=NoOpLogger(),
    )
    try:
        fail_service.place_order(
            customer="Bad Card",
            email="bad@test.com",
            items=[OrderItem("SKU-001", "Widget", 10.00, 1)],
        )
        assert False, "Should have raised"
    except RuntimeError:
        assert len(notifier.failed_orders) == 1
        print(f"  ✅ Test 2 passed: payment failure handled correctly")

Real-World Use Cases

DIP is most valuable wherever business logic must work independently of infrastructure:

Layered Architecture: The classic three-layer architecture (Presentation → Application → Infrastructure) uses DIP at every boundary. The Application layer defines repository and service interfaces. The Infrastructure layer implements them. The Application layer never imports from Infrastructure — the dependency arrow points inward, toward the business core.

Unit Testing Without Infrastructure: A CheckoutService that depends on a PaymentGateway interface can be tested with an AlwaysSucceedGateway or AlwaysFailGateway fake — no Stripe account, no network, tests run in milliseconds. Without DIP, testing checkout requires a live payment processor.

Feature Flags and A/B Testing: Inject different implementations based on a flag. new RecommendationService(useMLModel ? MLRecommender() : RuleBasedRecommender()). The service is unaware of which engine it uses — it just calls the abstraction.

Microservice Migration: A monolith with DIP can migrate a dependency from local to remote incrementally. UserRepository can be implemented as a local SQL call today and a remote gRPC call tomorrow — the UserService never changes. DIP makes the seam explicit.

Multi-Tenancy: Inject tenant-specific implementations at the composition root. TenantAMailer and TenantBMailer both implement Mailer. The business logic runs unchanged; only the injected implementation varies.

Event Sourcing: Define EventStore as an abstraction. Implement it first as an in-memory store for development, then as a Kafka producer for production. The command handlers never change — they depend only on EventStore.

Language-Specific Mistakes and Anti-Patterns

❌ Mistake #1: Instantiating Dependencies Inside __init__

# BAD: Business class creates its own infrastructure — untestable, inflexible
class OrderService:
    def __init__(self):
        self._repo    = MySQLOrderRepository()   # Hard-wired — DIP violation
        self._payment = StripeGateway()          # DIP violation
        self._mailer  = SendGridMailer()         # DIP violation

# To test OrderService you must have MySQL, Stripe credentials, and SendGrid configured.

# GOOD: Receive dependencies from outside
class OrderService:
    def __init__(
        self,
        repository: OrderRepository,
        payment:    PaymentGateway,
        mailer:     Mailer,
    ) -> None:
        self._repo    = repository
        self._payment = payment
        self._mailer  = mailer

❌ Mistake #2: Using Module-Level Globals as Hidden Dependencies

# BAD: Module-level database connection is a hidden dependency
import psycopg2
db = psycopg2.connect("postgresql://localhost/myapp")  # Hidden global dependency

class UserRepository:
    def find(self, user_id: int):
        cursor = db.cursor()  # Uses the global — cannot be replaced in tests
        cursor.execute("SELECT * FROM users WHERE id=%s", (user_id,))
        return cursor.fetchone()

# GOOD: Accept the connection as a dependency
class UserRepository:
    def __init__(self, connection) -> None:
        self._conn = connection  # Injected — real connection or test double

    def find(self, user_id: int):
        cursor = self._conn.cursor()
        cursor.execute("SELECT * FROM users WHERE id=%s", (user_id,))
        return cursor.fetchone()

Frequently Asked Questions

Q1: What is the difference between DIP and Dependency Injection?

DIP is a design principle — the rule that high-level modules should not depend on low-level modules; both should depend on abstractions. Dependency Injection (DI) is a technique — a pattern for implementing DIP by passing dependencies into a class through its constructor, method parameters, or properties rather than having the class create them internally. DIP tells you what the architecture should look like; DI tells you how to achieve it. You can satisfy DIP through DI, service locators, factory functions, or module-level configuration — DI is just the most common and cleanest approach.

Q2: Does DIP mean I need a DI container (Spring, ASP.NET Core, Dagger)?

No. DIP can be implemented with simple constructor injection and a hand-written composition root. DI containers automate the wiring at scale — when you have dozens of services with deep dependency trees, a container saves you from writing complex assembly code. But for small services or applications, manually assembling components at the main function is perfectly valid DIP. The principle is about the direction of dependencies, not about using a specific tool.

Q3: Where exactly is the "composition root"?

The composition root is the one place in the application that assembles concrete classes and wires them together. In a web application, this is typically the application startup code (ASP.NET Core's Program.cs, Spring's configuration classes, Express's index.js, Django's settings). In a CLI tool, it's the main function. In a test, the test setup method is a mini composition root — it wires test doubles. The key rule: only the composition root knows about concrete infrastructure classes. Everything else depends only on abstractions.

Q4: Should the interface be in the same package as the high-level module or in a shared package?

The interface should be in the same package/module as the high-level module that uses it, not in the package of the implementing class. This is the critical subtlety of DIP: the high-level module owns the abstraction. If UserRepository is in the database package, UserService (in business) still imports from database — the dependency is not inverted. When UserRepository lives in the business package alongside UserService, the business package has zero imports from database. The import arrow runs from database (which implements UserRepository) toward business (which defines it). That is the true inversion.

Q5: Can DIP be over-applied?

Yes. Defining an abstraction for a dependency that will never have a second implementation, that doesn't benefit from being faked in tests, or that is so simple that the abstraction adds more boilerplate than value is over-engineering. A logger that always writes to stdout doesn't need an interface in a simple script. The signal for applying DIP: would you want to substitute this dependency in tests or in different deployment configurations? If yes, the abstraction earns its place. If no, the abstraction adds indirection without value.

Q6: How does DIP relate to the other SOLID principles?

DIP is deeply complementary to all four other principles. It enables OCP — a module that depends only on abstractions is open for extension (new implementations) without modification. It supports LSP — abstractions define the behavioral contracts that implementations must honor. It works with ISP — the abstraction a high-level module defines should be focused (not fat), aligned with ISP. And it reinforces SRP — a class that receives its dependencies through injection has one reason to change (its own logic), not multiple reasons caused by the infrastructure it creates.

Q7: What is the difference between "Inversion of Control" and DIP?

Inversion of Control (IoC) is the broad principle that a framework or container, rather than application code, controls the flow of execution and the creation of objects. DIP is a more specific principle about the direction of source-code dependencies. IoC is one way to achieve DIP at scale — when a DI container creates and injects objects, the application code no longer controls instantiation (IoC) and the high-level modules no longer depend on low-level constructors (DIP). But DIP can be achieved without a framework through simple constructor injection, which is technically not IoC but fully satisfies DIP.

Q8: How do I test a class that follows DIP?

Testing a DIP-compliant class is straightforward: create in-memory test doubles for each abstraction, construct the class under test with those doubles, call the method, and assert on the results and on what the test doubles recorded. No real database, no real network, no real email server. Tests run in milliseconds. The test doubles can be hand-written classes, generated mocks (Mockito, Moq, mockk), or simple struct/object literals. The test's composition root is the test setup — it wires the class under test with its fakes exactly like the production composition root wires it with real implementations.

Key Takeaways

🎯 Core Concept: The Dependency Inversion Principle states that high-level modules should not depend on low-level modules — both should depend on abstractions, and abstractions should not depend on details. The practical meaning: your business logic should declare what it needs through an interface it owns; the infrastructure details implement that interface and are injected from outside. The dependency arrow runs from the infrastructure layer toward the abstraction, not from the business layer toward the infrastructure.

🔑 Key Benefits:

  • Testability: Business logic tested in milliseconds with in-memory fakes — no real database, no network, no credentials needed
  • Flexibility: Swap any infrastructure implementation (database engine, email provider, payment processor) without touching business logic
  • Isolation: A bug in the database layer cannot corrupt the business logic layer — they are separated by an abstraction boundary
  • Parallel development: Business logic and infrastructure developed independently against the shared interface contract
  • Reuse: Business modules work in any context that provides compatible implementations — web apps, CLI tools, batch jobs

🌐 Language-Specific Highlights:

  • Python: Use ABC and @abstractmethod to define abstractions; pass all dependencies through __init__ parameters; avoid module-level global connections
  • TypeScript: Keep interface files in the same module as the consuming business class, not in the infrastructure module; use constructor injection; prefer readonly fields
  • Java: Use Spring constructor injection rather than field injection with @Autowired; define interfaces in the service/domain layer, not in the repository layer
  • JavaScript: Keep infrastructure requires/imports out of business logic files entirely; assemble the object graph in a dedicated container.js or index.js at the application entry point
  • C#: Use ASP.NET Core's built-in DI container; register interfaces and implementations in Program.cs (the composition root); prefer constructor injection over property injection
  • PHP: Use constructor promotion with readonly for clean injection; use a DI container (Symfony, Laravel's container) in production; hand-wire in tests
  • Go: Define interfaces at the consumer side (in the package that uses them, not the package that implements them); pass interfaces, not concrete struct pointers
  • Rust: Use trait bounds for zero-cost compile-time polymorphism or Box<dyn Trait> for runtime polymorphism; pass the repository trait into the service constructor
  • Dart: Inject services into widgets via constructor, Provider, or Riverpod; never instantiate repositories inside initState
  • Swift: Use protocol for abstractions; inject via init for ViewModels; use environment values or dependency containers for SwiftUI
  • Kotlin: Use Hilt or Koin for DI in Android; hand-wire in pure domain module tests; prefer constructor injection over property injection

📋 When to Apply DIP:

  • A class instantiates infrastructure (database, HTTP client, email sender, file system) inside its own constructor or methods
  • Unit testing a business class requires spinning up real infrastructure
  • Swapping one infrastructure implementation for another requires editing business logic
  • Multiple deployment configurations (dev vs. prod, tenant A vs. tenant B) need different implementations of the same concept
  • You need to test failure paths (payment gateway rejects, database unavailable) without actually causing those failures

⚠️ When NOT to Over-Apply DIP:

  • A dependency will never have a second implementation and can't meaningfully be faked in tests
  • The abstraction adds more indirection than it removes coupling
  • A simple script or utility with no test requirements
  • The "infrastructure" is a standard library type that never changes (string formatting, math operations)

🛠️ Best Practices Across Languages:

  1. Own the abstraction at the high-level layer: The interface belongs with the business code that uses it, not with the infrastructure code that implements it
  2. Constructor injection is the default: Declare all dependencies in the constructor — they become explicit, immutable, and immediately visible to anyone reading the class
  3. Keep the composition root thin and focused: The composition root assembles concrete classes; it is the only file that imports from both business and infrastructure layers
  4. Build test doubles as first-class citizens: InMemoryRepository, FakePaymentGateway, SilentNotifier — invest in good fakes and they pay dividends in every test
  5. Inject even simple dependencies when they involve I/O: A clock, a random number generator, a feature flag reader — all are dependencies that benefit from injection when their behavior needs to vary in tests

💡 Common Pitfalls:

  • new inside constructors: The single most common DIP violation — if you see this.repo = new MySQLRepository() inside a constructor, the dependency is hard-wired
  • Concrete type parameters: A function or constructor that accepts *MySQLRepository instead of RepositoryInterface is coupled to the concrete type
  • Infrastructure imports in business files: A using, import, or require for a database driver, email SDK, or HTTP client inside a business logic file is a DIP violation visible in the import list
  • Shared module anti-pattern: Putting interfaces in a "shared" or "common" module that both business and infrastructure import — the interface should be owned by the business layer, not by a neutral third module
  • Testing with the real DI container: Tests that spin up the full application container to test a single service are integration tests, not unit tests. DIP-compliant code should be unit-testable with manual injection

🎁 Advanced Patterns Enabled by DIP:

  • Decorator Pattern: Wrap an implementation with cross-cutting concerns (caching, logging, retry) by creating a decorator class that implements the same interface and wraps the real implementation. The business logic sees no change.
  • Adapter Pattern: Adapt a third-party interface to your own abstraction. Wrap Stripe's SDK in a PaymentGateway adapter — the business logic never knows Stripe exists.
  • Repository Pattern with Specifications: Combine DIP with the Specification pattern — pass query objects to a find(spec: Specification<T>) method on the repository interface. Business logic constructs specifications; infrastructure translates them to SQL.
  • CQRS: Define separate CommandRepository and QueryRepository interfaces (aligned with ISP). Implement the command side with a write-optimized store; implement the query side with a read-optimized projection. Business logic is unaware of the dual storage strategy.

The Dependency Inversion Principle is the architectural principle that gives business logic its independence. In a codebase that follows DIP, business rules can be written, tested, and reasoned about without a single live database, live API, or live service in sight. Infrastructure becomes pluggable detail — swapped at startup, faked in tests, and evolved without touching the code that matters most.

Want to dive deeper into SOLID principles? Check out our comprehensive guides on: