Может ли работать Dependency Inversion без Dependency Injection?

Dependency Inversion без Dependency Injection — возможно ли?

Краткий ответ: Нет, Dependency Inversion (DI) не может полноценно работать без Dependency Injection (DI). Это разные концепции, но они неразрывно связаны.

Определения

Dependency Inversion Principle (SOLID)

Принцип: Высокоуровневые модули не должны зависеть от низкоуровневых. Обе должны зависеть от абстракций.

# ❌ ПЛОХО: Высокоуровневый класс зависит от низкоуровневого
class MySQLDatabase:
    def save(self, data):
        pass

class UserService:  # Высокоуровневый
    def __init__(self):
        self.db = MySQLDatabase()  # Жёсткая зависимость!
    
    def create_user(self, name):
        self.db.save(name)

# ✅ ХОРОШО: Оба зависят от абстракции
from abc import ABC, abstractmethod

class DatabaseInterface(ABC):  # Абстракция
    @abstractmethod
    def save(self, data):
        pass

class MySQLDatabase(DatabaseInterface):
    def save(self, data):
        pass

class PostgresDatabase(DatabaseInterface):
    def save(self, data):
        pass

class UserService:  # Зависит от абстракции, не от конкретной БД
    def __init__(self, db: DatabaseInterface):
        self.db = db
    
    def create_user(self, name):
        self.db.save(name)

Dependency Injection (DI)

Метод: Передача зависимостей извне, а не создание их внутри класса.

# Создаём объекты вне класса и инъектим их
db = MySQLDatabase()
service = UserService(db)  # Injection!
service.create_user("Alice")

# Можем переключиться на другую БД
db = PostgresDatabase()
service = UserService(db)  # DI позволяет это!
service.create_user("Bob")

Может ли работать Dependency Inversion БЕЗ Dependency Injection?

Технически да, но практически нет. Вот почему:

Вариант 1: Service Locator (антипаттерн)

class ServiceLocator:
    """Глобальный реестр сервисов"""
    _services = {}
    
    @classmethod
    def register(cls, name, service):
        cls._services[name] = service
    
    @classmethod
    def get(cls, name):
        return cls._services[name]

# Регистрация
ServiceLocator.register("database", MySQLDatabase())

class UserService:
    def __init__(self):
        # Получаем из глобального реестра вместо создания
        self.db = ServiceLocator.get("database")
    
    def create_user(self, name):
        self.db.save(name)

service = UserService()

Проблемы:

• Скрытые зависимости (читаешь код, не видишь откуда берётся БД)
• Сложно тестировать (нужно мокировать глобальный реестр)
• Тесная связь с ServiceLocator

Вариант 2: Factory pattern

class UserServiceFactory:
    @staticmethod
    def create():
        db = MySQLDatabase()  # Создание внутри
        return UserService(db)

service = UserServiceFactory.create()

Проблемы:

• Всё равно зависит от конкретной реализации (MySQLDatabase)
• Для переключения БД нужно менять код Factory
• Не решает проблему плотной связи

Вариант 3: Module-level singleton (Python специфический)

# db.py
class Database:
    pass

# Глобальный экземпляр
_instance = MySQLDatabase()

def get_db():
    return _instance

def set_db(db):
    global _instance
    _instance = db

# service.py
from db import get_db

class UserService:
    def __init__(self):
        self.db = get_db()  # Зависит от абстракции (принцип есть)
    
    def create_user(self, name):
        self.db.save(name)

# Использование
from db import set_db
set_db(PostgresDatabase())

Проблемы:

• Скрытые зависимости
• Глобальное состояние (threading issues)
• Сложно тестировать

Почему DI необходима для DIP

Проблема без DI

# Пытаемся сделать DIP без DI
class DatabaseInterface(ABC):
    @abstractmethod
    def save(self, data):
        pass

class UserService:
    def __init__(self):
        # ПРОБЛЕМА: Зависит от конкретной реализации
        # Нарушает DIP!
        self.db = MySQLDatabase()  # Жёсткая связь
    
    def create_user(self, name):
        self.db.save(name)

# Для тестов нужно переписывать UserService
# Это нарушает принцип Open/Closed

Решение с DI

class UserService:
    def __init__(self, db: DatabaseInterface):  # DI
        self.db = db  # Зависит от абстракции
    
    def create_user(self, name):
        self.db.save(name)

# Production
service = UserService(MySQLDatabase())

# Tests
class MockDatabase(DatabaseInterface):
    def save(self, data):
        pass

test_service = UserService(MockDatabase())

Пример: DIP без DI vs с DI

БЕЗ DI (плохо)

# auth.py
class EmailService(ABC):
    @abstractmethod
    def send(self, email, message):
        pass

class SmtpEmailService(EmailService):
    def send(self, email, message):
        print(f"Email sent to {email}")

class UserAuth:
    def __init__(self):
        # DIP нарушена! Зависит от конкретной реализации
        self.email = SmtpEmailService()
    
    def register(self, email, password):
        self.email.send(email, "Welcome!")

# Для тестов очень сложно
auth = UserAuth()  # Всегда SmtpEmailService
# Нельзя использовать MockEmailService без переписания класса

С DI (хорошо)

class UserAuth:
    def __init__(self, email: EmailService):  # DI
        self.email = email  # DIP соблюдена!
    
    def register(self, email, password):
        self.email.send(email, "Welcome!")

# Production
email_service = SmtpEmailService()
auth = UserAuth(email_service)

# Testing — легко подменить
class MockEmailService(EmailService):
    def send(self, email, message):
        self.last_email = email

mock_email = MockEmailService()
test_auth = UserAuth(mock_email)
test_auth.register("test@example.com", "pass")
assert mock_email.last_email == "test@example.com"

Профессиональный подход: DI контейнер

# Python DI контейнеры: dependency-injector, injector, pinject
from dependency_injector import containers, providers

class Container(containers.DeclarativeContainer):
    # Конфигурация всех зависимостей
    database = providers.Singleton(
        MySQLDatabase,
        host="localhost",
        port=3306
    )
    
    email_service = providers.Singleton(
        SmtpEmailService,
        smtp_server="smtp.gmail.com"
    )
    
    user_service = providers.Factory(
        UserService,
        db=database,
        email=email_service
    )

# Использование
container = Container()
service = container.user_service()  # Все зависимости инъектены автоматически

Таблица сравнения подходов

Резюме

Может ли DIP работать без DI?

• Практически НЕТ — DIP без DI это просто абстракции, которые никто не использует
• Допустимо: Service Locator (антипаттерн, но работает)
• НЕ рекомендуется: Factory, глобальные синглтоны
• Лучшее решение: Constructor DI (передача через __init__)
• Профессиональное: DI контейнер (dependency-injector)

Золотое правило: DIP и DI работают вместе. Без DI ты теряешь основное преимущество DIP — возможность легко менять реализацию.