What is Dependency Injection in Programming?

Personal Knowledge Sharing: How understanding dependency injection changed the way I structure Python applications

Introduction

I remember the first time I looked at a service class I'd written for my multi-tenant POS backend and thought: "why is this so hard to test?" Every time I tried to write a unit test, the service was already wired up to a live PostgreSQL connection, a real Redis client, and a third-party billing API call inside the constructor. To test a single method I had to either mock the entire world or spin up real infrastructure.

That pain pointed me to one root cause — tight coupling. My classes were building their own dependencies internally. Once I understood Dependency Injection (DI), I stopped constructing dependencies inside classes and started receiving them from outside. It sounds like a small shift, but it changes how you design, test, and maintain every layer of a system.

This article covers what DI is, why it matters, how it works in Python without any framework, and how the pattern shows up naturally in FastAPI through its Depends() system.

---

Table of Contents

• What is a Dependency?

• The Problem: Tight Coupling

• What is Dependency Injection?

• Types of Dependency Injection

  • Constructor Injection

  • Setter Injection

  • Interface Injection

• Python Protocols as Interfaces

• DI in a FastAPI Service Layer

• How the Flow Looks at Runtime

• Testing Becomes Straightforward

• What I Learned

---

What is a Dependency?

A dependency is any external object, service, or resource that a class or function needs to do its job.

Common examples in backend Python work:

• A database session or repository

• An HTTP client calling an external API

• A cache client (Redis)

• A logger

• A configuration object

• A message queue publisher

When a class creates one of these itself, it owns the dependency. When it receives one from outside, it uses the dependency. Dependency Injection is the practice of providing dependencies from the outside rather than creating them internally.

---

The Problem: Tight Coupling

Here is a pattern that was common in my early codebase. A ReportService that needs a database connection:

import psycopg2

class ReportService:
    def __init__(self):
        # The service builds its own dependency — tight coupling
        self.conn = psycopg2.connect(
            host="localhost",
            dbname="pos_db",
            user="admin",
            password="secret"
        )

    def get_daily_sales(self, date: str) -> list[dict]:
        cursor = self.conn.cursor()
        cursor.execute(
            "SELECT item_id, quantity, total FROM sales WHERE sale_date = %s",
            (date,)
        )
        return cursor.fetchall()

This looks harmless, but hits three problems immediately:

1. Untestable in isolation — instantiating ReportService always opens a real database connection. There is no way to supply a fake database in a unit test.

2. Hard to swap implementations — if the team moves from psycopg2 to asyncpg or SQLAlchemy, the change is buried inside the service class.

3. Hidden configuration — connection credentials are hardcoded into the class constructor, which leaks environment concerns into business logic.

The red nodes represent tightly coupled code. You cannot take ReportService out of this wiring and use it elsewhere.

---

What is Dependency Injection?

Dependency Injection means that the dependencies a class needs are provided to it from outside — typically through the constructor, a setter method, or a function parameter — rather than created inside.

The class declares what it needs without caring how it was built.

The creation of DBConnection now belongs to a composition root — a single place responsible for wiring the application together. ReportService is kept clean of that concern.

---

Types of Dependency Injection

1. Constructor Injection

The most common form. Dependencies are declared as parameters in __init__. The caller is forced to supply them — there is no ambiguity about what the class needs.

from typing import Protocol


class SalesRepository(Protocol):
    def fetch_daily_sales(self, date: str) -> list[dict]: ...


class ReportService:
    def __init__(self, repository: SalesRepository) -> None:
        # Receive the dependency, don't build it
        self._repository = repository

    def get_daily_sales(self, date: str) -> list[dict]:
        return self._repository.fetch_daily_sales(date)

The SalesRepository parameter is a Protocol (covered in the next section). ReportService does not know or care whether it receives a real PostgreSQL repository or a test double.

---

2. Setter Injection

Dependencies are supplied through a dedicated method after the object is constructed. I use this pattern sparingly — only when an optional collaborator can be swapped at runtime, such as plugging in a different logging backend.

import logging


class ReportService:
    def __init__(self, repository: SalesRepository) -> None:
        self._repository = repository
        self._logger = logging.getLogger(__name__)  # sensible default

    def set_logger(self, logger: logging.Logger) -> None:
        # Allow a custom logger to be injected after construction
        self._logger = logger

    def get_daily_sales(self, date: str) -> list[dict]:
        self._logger.info("Fetching daily sales for %s", date)
        return self._repository.fetch_daily_sales(date)

The risk with setter injection is that the object can be in an incomplete state between construction and calling the setter. Constructor injection avoids that entirely, which is why I default to it.

---

3. Interface Injection

The class advertises a setter contract through an interface (Protocol). Any dependency that wants to inject itself must implement the protocol. This is less common in Python because Protocol and duck typing usually handle the contract more cleanly through constructor injection.

I have not found a strong reason to use this form in Python work; constructor injection with Protocol covers the same intent.

---

Python Protocols as Interfaces

Python's typing.Protocol is the right tool for defining the shape a dependency must have without requiring inheritance. This keeps classes decoupled at the type level while still giving mypy enough information to catch mismatches.

Here is the full pattern I use across service layers:

# protocols.py
from typing import Protocol


class SalesRepository(Protocol):
    def fetch_daily_sales(self, date: str) -> list[dict]: ...
    def fetch_item_breakdown(self, item_id: int) -> dict: ...


class CacheClient(Protocol):
    def get(self, key: str) -> str | None: ...
    def set(self, key: str, value: str, ttl: int = 300) -> None: ...

# repositories/postgres_sales_repository.py
import psycopg2


class PostgresSalesRepository:
    def __init__(self, conn: psycopg2.extensions.connection) -> None:
        self._conn = conn

    def fetch_daily_sales(self, date: str) -> list[dict]:
        cursor = self._conn.cursor()
        cursor.execute(
            "SELECT item_id, quantity, total FROM sales WHERE sale_date = %s",
            (date,)
        )
        rows = cursor.fetchall()
        return [{"item_id": r[0], "quantity": r[1], "total": r[2]} for r in rows]

    def fetch_item_breakdown(self, item_id: int) -> dict:
        cursor = self._conn.cursor()
        cursor.execute(
            "SELECT item_id, name, category FROM items WHERE id = %s",
            (item_id,)
        )
        row = cursor.fetchone()
        return {"item_id": row[0], "name": row[1], "category": row[2]} if row else {}

# services/report_service.py
from protocols import SalesRepository, CacheClient
import json


class ReportService:
    def __init__(
        self,
        repository: SalesRepository,
        cache: CacheClient,
    ) -> None:
        self._repository = repository
        self._cache = cache

    def get_daily_sales(self, date: str) -> list[dict]:
        cache_key = f"daily_sales:{date}"
        cached = self._cache.get(cache_key)

        if cached:
            return json.loads(cached)

        results = self._repository.fetch_daily_sales(date)
        self._cache.set(cache_key, json.dumps(results), ttl=600)
        return results

ReportService now depends on two abstractions — SalesRepository and CacheClient. The concrete implementations (PostgresSalesRepository, RedisClient) are assembled elsewhere and injected in.

---

DI in a FastAPI Service Layer

FastAPI's Depends() function is a first-class DI system. When I moved the POS reporting endpoints into a FastAPI application, the framework took over the role of the composition root — it builds dependencies and injects them into route handlers automatically.

# dependencies.py
from fastapi import Depends
import psycopg2
import redis

from repositories.postgres_sales_repository import PostgresSalesRepository
from services.report_service import ReportService


def get_db_connection() -> psycopg2.extensions.connection:
    conn = psycopg2.connect(
        host="localhost",
        dbname="pos_db",
        user="admin",
        password="secret",
    )
    try:
        yield conn
    finally:
        conn.close()


def get_cache_client() -> redis.Redis:
    client = redis.Redis(host="localhost", port=6379, decode_responses=True)
    try:
        yield client
    finally:
        client.close()


def get_report_service(
    conn=Depends(get_db_connection),
    cache=Depends(get_cache_client),
) -> ReportService:
    repository = PostgresSalesRepository(conn)
    return ReportService(repository=repository, cache=cache)

# routers/reports.py
from fastapi import APIRouter, Depends
from dependencies import get_report_service
from services.report_service import ReportService

router = APIRouter(prefix="/reports", tags=["reports"])


@router.get("/daily/{date}")
def daily_sales_report(
    date: str,
    service: ReportService = Depends(get_report_service),
):
    return service.get_daily_sales(date)

FastAPI resolves the entire dependency graph in get_report_service before the route handler runs. The route handler receives a fully assembled ReportService and never sees the database connection or cache client.

---

How the Flow Looks at Runtime

The route handler never calls psycopg2.connect or redis.Redis(...) directly. Those decisions live in dependencies.py, which is the composition root for this application.

---

Testing Becomes Straightforward

The clearest payoff from DI is in tests. Because ReportService accepts SalesRepository and CacheClient as constructor parameters, I can pass in test doubles — no mocking frameworks required for the core logic.

# tests/test_report_service.py
import pytest
from services.report_service import ReportService


class InMemorySalesRepository:
    """Test double that satisfies SalesRepository protocol."""

    def __init__(self, data: list[dict]) -> None:
        self._data = data

    def fetch_daily_sales(self, date: str) -> list[dict]:
        return [row for row in self._data if row["date"] == date]

    def fetch_item_breakdown(self, item_id: int) -> dict:
        return {}


class InMemoryCache:
    """Test double that satisfies CacheClient protocol."""

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

    def get(self, key: str) -> str | None:
        return self._store.get(key)

    def set(self, key: str, value: str, ttl: int = 300) -> None:
        self._store[key] = value


def test_get_daily_sales_returns_correct_records():
    seed_data = [
        {"date": "2026-03-26", "item_id": 1, "quantity": 10, "total": 500.0},
        {"date": "2026-03-25", "item_id": 2, "quantity": 5, "total": 250.0},
    ]
    repo = InMemorySalesRepository(data=seed_data)
    cache = InMemoryCache()
    service = ReportService(repository=repo, cache=cache)

    result = service.get_daily_sales("2026-03-26")

    assert len(result) == 1
    assert result[0]["item_id"] == 1


def test_get_daily_sales_uses_cache_on_second_call():
    seed_data = [
        {"date": "2026-03-26", "item_id": 1, "quantity": 10, "total": 500.0},
    ]
    repo = InMemorySalesRepository(data=seed_data)
    cache = InMemoryCache()
    service = ReportService(repository=repo, cache=cache)

    # First call — populates cache
    service.get_daily_sales("2026-03-26")

    # Poison the repository so any direct call would return empty
    repo._data = []

    # Second call — should still return from cache
    result = service.get_daily_sales("2026-03-26")

    assert len(result) == 1

No patching, no monkeypatching the module, no unittest.mock.patch gymnastics. The test constructs real Python objects, and they work because the interface contract is honoured.

For FastAPI routes, the framework provides app.dependency_overrides to swap dependencies during integration tests:

# tests/test_reports_router.py
from fastapi.testclient import TestClient
from main import app
from dependencies import get_report_service
from services.report_service import ReportService


def override_report_service() -> ReportService:
    repo = InMemorySalesRepository(data=[
        {"date": "2026-03-26", "item_id": 1, "quantity": 3, "total": 150.0}
    ])
    cache = InMemoryCache()
    return ReportService(repository=repo, cache=cache)


app.dependency_overrides[get_report_service] = override_report_service
client = TestClient(app)


def test_daily_sales_endpoint():
    response = client.get("/reports/daily/2026-03-26")
    assert response.status_code == 200
    assert len(response.json()) == 1

The application never touches a real database or Redis instance during this test run.

---

Architectural Overview

The business logic in ReportService never points at a concrete implementation. It points at protocols. Both production and test layers satisfy those protocols independently.

---

What I Learned

After applying DI consistently across my Python projects — from ansible-inspec's FastAPI service layer to the multi-tenant POS reporting backend — a few things became clear:

Start with constructor injection. It is explicit and honest. The constructor signature is the public contract — it tells every caller what the class needs to function. I avoided setter injection unless there was a genuine runtime-swapping requirement.

typing.Protocol is the right tool in Python. I do not use abstract base classes (abc.ABC) for this anymore. Protocol enables structural subtyping — a class satisfies the protocol if it has the right methods, regardless of inheritance. This keeps the concrete implementations free of framework coupling.

FastAPI's Depends() is DI done right at the framework level. I did not need to reach for dependency-injector or any third-party container. FastAPI's dependency graph handles lifetime management (request-scoped vs. application-scoped), cleanup via yield, and test overrides through dependency_overrides. That covers the vast majority of what a DI container does, with no additional setup.

The real win is at test time. Saying "DI makes code testable" is a cliché — but it is genuinely true. When I stopped constructing dependencies inside classes, test setup dropped from twenty lines of mocking scaffolding to three lines of plain Python object construction.

DI is not magic wiring. A DI container is optional. Python's standard library and FastAPI's built-in system are more than enough for a service-oriented backend. The valuable idea is the pattern itself: declare what you need, don't build what you need.

---

These patterns come from hands-on experience building FastAPI-based services and the ansible-inspec project. The code examples reflect structures I have actually used rather than simplified toy examples.