Что означает слово инверсия в инверсии зависимости?

Инверсия в Инверсии Зависимости

Инверсия зависимости (Dependency Inversion Principle, DIP) — один из ключевых принципов SOLID, который переворачивает традиционный порядок зависимостей в коде. Слово инверсия означает именно этот поворот с ног на голову классического подхода к архитектуре.

Суть инверсии

В классическом подходе высокоуровневые модули зависят от низкоуровневых деталей реализации:

# ❌ Плохой подход — прямая зависимость
class UserService:
    def __init__(self):
        self.db = PostgreSQLDatabase()  # Жесткая привязка
    
    def get_user(self, user_id):
        return self.db.query(f"SELECT * FROM users WHERE id = {user_id}")

Здесь UserService (высокоуровневый модуль) напрямую зависит от PostgreSQLDatabase (низкоуровневая реализация). Если нужно переключиться на MySQL или MongoDB, придется менять сам сервис.

Инверсия — это переворот: теперь оба модуля зависят от абстракции:

# ✅ Правильный подход — зависимость от абстракции
from abc import ABC, abstractmethod

class DatabaseInterface(ABC):
    @abstractmethod
    def query(self, sql: str):
        pass

class PostgreSQLDatabase(DatabaseInterface):
    def query(self, sql: str):
        return f"Execute in PostgreSQL: {sql}"

class MongoDatabase(DatabaseInterface):
    def query(self, sql: str):
        return f"Execute in MongoDB: {sql}"

class UserService:
    def __init__(self, db: DatabaseInterface):  # Инъекция абстракции
        self.db = db
    
    def get_user(self, user_id):
        return self.db.query(f"SELECT * FROM users WHERE id = {user_id}")

Теперь UserService не знает о конкретной реализации БД — только об интерфейсе. Это и есть инверсия: раньше высокоуровневый код диктовал низкоуровневому, а теперь оба следуют контракту абстракции.

Почему это важно

Тестируемость: легко подставить mock-объект для тестов:

class MockDatabase(DatabaseInterface):
    def query(self, sql: str):
        return {"id": 1, "name": "Test User"}

service = UserService(MockDatabase())
assert service.get_user(1) == {"id": 1, "name": "Test User"}

Гибкость: меняешь реализацию БД без изменений UserService:

service_pg = UserService(PostgreSQLDatabase())
service_mongo = UserService(MongoDatabase())

Независимость: оба модуля развиваются независимо, следуя одному контракту.

Практический пример с фреймворками

В FastAPI это реализуется через dependency injection:

from fastapi import Depends

class UserRepository(ABC):
    @abstractmethod
    async def get_by_id(self, user_id: int):
        pass

class PostgresUserRepository(UserRepository):
    async def get_by_id(self, user_id: int):
        # Запрос в БД
        return {"id": user_id}

async def get_repository() -> UserRepository:
    return PostgresUserRepository()  # В тестах подставляем Mock

@app.get("/users/{user_id}")
async def get_user(user_id: int, repo: UserRepository = Depends(get_repository)):
    return await repo.get_by_id(user_id)

Высокоуровневый код (роут) зависит от абстракции UserRepository, а не от конкретной PostgresUserRepository. При необходимости в тестах или в production меняешь реализацию в точке — функции get_repository().

Два принципа DIP

1. Высокоуровневые модули не должны зависеть от низкоуровневых — оба зависят от абстракции
2. Абстракции не должны зависеть от деталей — детали реализации зависят от абстракции

Это и есть инверсия: традиционно низкоуровневые детали диктуют архитектуру, а по DIP высокоуровневая бизнес-логика определяет контракты, которым должны следовать детали.

Резюме

Слово инверсия — это буквально перелом: вместо того чтобы код зависел от конкретных реализаций, мы инвертируем зависимости так, чтобы все зависели от абстракций. Результат: код становится гибче, тестируемее и поддерживаемее.