Как в коде уйти от Mixins?

Избегание Mixins: когда это плохо и что выбрать вместо

Mixins часто кажутся удобным способом переиспользовать код, но они создают сложную иерархию наследования и нарушают принцип Single Responsibility. Расскажу почему они плохи и какие есть альтернативы.

Почему Mixins — плохая идея

Проблемы:

• Неявная иерархия: непонятно, откуда берутся методы
• Множественное наследование: MRO (Method Resolution Order) — кошмар для отладки
• Сложно тестировать: нужно создавать странные вспомогательные классы
• Хрупкий код: изменение порядка наследования ломает всё
• Нарушение SOLID: один класс получает слишком много ответственности

# ❌ Плохо: типичный кошмар с mixins
class LoggingMixin:
    def log(self, msg): ...

class ValidationMixin:
    def validate(self): ...

class PersistenceMixin:
    def save(self): ...

class User(LoggingMixin, ValidationMixin, PersistenceMixin, BaseModel):
    name: str

# Кто отвечает за что? Неясно!
# MRO: User -> LoggingMixin -> ValidationMixin -> PersistenceMixin -> BaseModel

1. Композиция вместо наследования

Вместо того чтобы наследоваться от Mixin'а, передай функциональность как зависимость:

# ✅ Хорошо: явная композиция
class Logger:
    def log(self, msg: str) -> None:
        print(f"[LOG] {msg}")

class Validator:
    def validate(self, data: dict) -> bool:
        return len(data.get('name', '')) > 0

class UserRepository:
    def save(self, user: 'User') -> None:
        print(f"Сохранил {user.name}")

class User:
    def __init__(
        self,
        name: str,
        logger: Logger,
        validator: Validator,
        repository: UserRepository
    ):
        self.name = name
        self.logger = logger
        self.validator = validator
        self.repository = repository
    
    def create(self) -> None:
        self.logger.log(f"Создаю пользователя {self.name}")
        if self.validator.validate({'name': self.name}):
            self.repository.save(self)
        else:
            self.logger.log("Валидация не прошла")

# Использование
logger = Logger()
validator = Validator()
repository = UserRepository()
user = User("Alice", logger, validator, repository)
user.create()

Плюсы:

• Явная зависимость (видно сразу, что нужно)
• Легко тестировать (подставь mock'и)
• Нет проблем с MRO
• Каждый класс отвечает за одно

2. Через конструктор с наследованием типов

Если всё же нужно наследование, используй типы вместо множественного наследования:

# ✅ Лучше чем Mixins: Protocol (interface)
from typing import Protocol

class Loggable(Protocol):
    def log(self, msg: str) -> None: ...

class Persistable(Protocol):
    def save(self) -> None: ...

class User(Loggable, Persistable):
    """User имплементирует интерфейсы, но не наследует код"""
    def log(self, msg: str) -> None:
        print(f"[LOG] {msg}")
    
    def save(self) -> None:
        print(f"Сохранил {self.name}")

3. Функциональный подход: декораторы

Для поведения, которое применяется ко многим классам, используй декораторы:

# ✅ Хорошо: декоратор для логирования
from functools import wraps

def logged(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        print(f"Вызываю {func.__name__}")
        result = func(*args, **kwargs)
        print(f"Закончил {func.__name__}")
        return result
    return wrapper

class User:
    @logged
    def save(self):
        return "Сохранено"

user = User()
user.save()  # Вывод: Вызываю save, Закончил save

4. Dependency Injection контейнер

Для более сложных случаев используй DI контейнер (например, dependency-injector):

from dependency_injector import containers, providers

class Container(containers.DeclarativeContainer):
    config = providers.Configuration()
    
    logger = providers.Singleton(Logger)
    validator = providers.Singleton(Validator)
    repository = providers.Singleton(UserRepository)
    
    user_service = providers.Factory(
        UserService,
        logger=logger,
        validator=validator,
        repository=repository
    )

# Использование
container = Container()
user_service = container.user_service()

5. Trait pattern через функции высшего порядка

Для функционального стиля:

# ✅ Хорошо: функции как "трейты"
def with_logging(cls):
    """Добавляет логирование к классу (без наследования!)"""
    original_init = cls.__init__
    
    def new_init(self, *args, **kwargs):
        print(f"Инициализирую {cls.__name__}")
        original_init(self, *args, **kwargs)
    
    cls.__init__ = new_init
    return cls

@with_logging
class User:
    def __init__(self, name: str):
        self.name = name

user = User("Alice")  # Вывод: Инициализирую User

6. Dataclass с composition

Для простых случаев — dataclass с явным составом:

from dataclasses import dataclass, field

@dataclass
class User:
    name: str
    logger: Logger = field(default_factory=Logger)
    validator: Validator = field(default_factory=Validator)
    
    def create(self) -> None:
        self.logger.log(f"Создаю {self.name}")
        if self.validator.validate({'name': self.name}):
            print("Успешно")

7. Service Locator (когда DI не подходит)

Для legacy кода или фреймворков, где DI сложно:

class ServiceLocator:
    _services = {}
    
    @classmethod
    def register(cls, name: str, service):
        cls._services[name] = service
    
    @classmethod
    def get(cls, name: str):
        return cls._services.get(name)

ServiceLocator.register('logger', Logger())
ServiceLocator.register('validator', Validator())

class User:
    def __init__(self, name: str):
        self.name = name
        self.logger = ServiceLocator.get('logger')
        self.validator = ServiceLocator.get('validator')

Сравнение подходов

Итого

Правило простой: если ловишь себя на написании Mixin'а, остановись и подумай:

1. Нужна ли переиспользуемая функциональность? → Используй Composition
2. Нужна ли типизация интерфейса? → Используй Protocol
3. Нужно обернуть поведение? → Используй Decorator
4. Сложная система зависимостей? → Используй DI Container

Mixin'ы — это сигнал, что архитектура нуждается в переработке.