Какая проблема происходит, когда зависимость в коде не инвертирована?

Проблема неинвертированной зависимости

Основная проблема: код становится жёстко связанным (tightly coupled), что приводит к сложности в тестировании, расширении и поддержке.

Что такое инверсия зависимостей?

Принцип Dependency Inversion (DI) из SOLID гласит:

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

Если это нарушено — зависимость не инвертирована.

Проблема 1: жёсткая связанность (Tight Coupling)

Плохо — зависимость не инвертирована

class PaymentProcessor:
    def __init__(self):
        # Жёсткая зависимость от конкретной реализации
        self.payment_gateway = StripeGateway()
    
    def process_payment(self, amount):
        return self.payment_gateway.charge(amount)

class StripeGateway:
    def charge(self, amount):
        # Логика зарядить через Stripe
        pass

Проблема: если нужно переключиться на PayPal, нужно изменять PaymentProcessor.

Хорошо — зависимость инвертирована

from abc import ABC, abstractmethod

class PaymentGateway(ABC):
    @abstractmethod
    def charge(self, amount):
        pass

class PaymentProcessor:
    def __init__(self, gateway: PaymentGateway):
        # Зависимость от абстракции, а не конкретной реализации
        self.payment_gateway = gateway
    
    def process_payment(self, amount):
        return self.payment_gateway.charge(amount)

class StripeGateway(PaymentGateway):
    def charge(self, amount):
        pass

class PayPalGateway(PaymentGateway):
    def charge(self, amount):
        pass

# Легко переключаются
processor = PaymentProcessor(StripeGateway())
# или
processor = PaymentProcessor(PayPalGateway())

Проблема 2: сложность тестирования

Плохо — невозможно тестировать изолировано

class UserRepository:
    def __init__(self):
        self.db = DatabaseConnection("postgresql://...")
    
    def get_user(self, user_id):
        return self.db.query(f"SELECT * FROM users WHERE id = {user_id}")

class UserService:
    def __init__(self):
        # Жёсткая зависимость от реальной БД
        self.repo = UserRepository()
    
    def activate_user(self, user_id):
        user = self.repo.get_user(user_id)
        user.active = True
        # сохранение в БД...
        return user

# Тест требует РЕАЛЬНУЮ БД
service = UserService()
user = service.activate_user(123)  # Тест медленный и хрупкий!

Хорошо — можно использовать Mock

from abc import ABC, abstractmethod
from unittest.mock import Mock

class Repository(ABC):
    @abstractmethod
    def get_user(self, user_id):
        pass

class UserService:
    def __init__(self, repo: Repository):
        # Зависимость инвертирована
        self.repo = repo
    
    def activate_user(self, user_id):
        user = self.repo.get_user(user_id)
        user.active = True
        return user

# Тест с mock-ом
mock_repo = Mock()
mock_repo.get_user.return_value = Mock(active=False)
service = UserService(mock_repo)
user = service.activate_user(123)
assert user.active == True  # Быстрый, чистый тест!

Проблема 3: сложность расширения

Плохо — каждое изменение требует модификации

class Logger:
    def log(self, message):
        print(message)  # Логирование в console

class OrderService:
    def __init__(self):
        self.logger = Logger()
    
    def process_order(self, order):
        self.logger.log(f"Processing order {order.id}")
        # логика...

# Нужно логировать в файл? Нужно изменять OrderService!
# Нужно логировать в Slack? Опять изменять!

Хорошо — легко добавлять новые реализации

from abc import ABC, abstractmethod

class Logger(ABC):
    @abstractmethod
    def log(self, message):
        pass

class ConsoleLogger(Logger):
    def log(self, message):
        print(message)

class FileLogger(Logger):
    def log(self, message):
        with open('app.log', 'a') as f:
            f.write(message + '\n')

class SlackLogger(Logger):
    def log(self, message):
        requests.post('https://hooks.slack.com/...', json={'text': message})

class OrderService:
    def __init__(self, logger: Logger):
        self.logger = logger
    
    def process_order(self, order):
        self.logger.log(f"Processing order {order.id}")

# Легко переключаются
service = OrderService(ConsoleLogger())
# или
service = OrderService(FileLogger())
# или
service = OrderService(SlackLogger())

Проблема 4: хрупкость и каскадные ошибки

# Плохо — множество зависимостей создаются в конструкторе
class ComplexService:
    def __init__(self):
        self.db = DatabaseConnection()
        self.cache = RedisCache()
        self.email = EmailSender()
        self.logger = Logger()
        self.analytics = AnalyticsService()

# Если любой из них упадёт — упадёт весь сервис
service = ComplexService()  # Может выбросить исключение

Практический совет на собеседовании

"Когда зависимость не инвертирована, код становится жёстко связанным, что затрудняет тестирование, расширение и поддержку. Решение: зависимости передаются через конструктор или setter, а не создаются внутри класса. Это позволяет легко подменять реализации, использовать mock-и в тестах и расширять функционал без изменения существующего кода."

Вывод

Неинвертированные зависимости приводят к:

1. Жёсткой связанности — код сложно менять
2. Сложности тестирования — нельзя использовать mock-и
3. Сложности расширения — каждое изменение требует рефакторинга
4. Хрупкости — ошибка в одном модуле ломает всё остальное

Инверсия зависимостей решает все эти проблемы.