Каковы преимущества и недостатки композиции в объектно-ориентированном программировании (ООП)?

Композиция — это принцип ООП, при котором класс содержит экземпляры других классов (компонентов) в качестве своих полей. Это позволяет строить сложные объекты из более простых, делегируя им часть функциональности. Композиция выражает отношение "has-a" (имеет), в отличие от наследования, которое выражает "is-a" (является).

Преимущества композиции:

1. Гибкость и динамичность: Компоненты можно легко заменять, добавлять или удалять во время выполнения, что позволяет динамически изменять поведение объекта без изменения его класса. Это способствует созданию более адаптивных систем.
2. Снижение связанности (Low Coupling): Классы зависят от интерфейсов компонентов, а не от их конкретных реализаций. Это уменьшает жесткую связность между классами, делая систему более модульной, устойчивой к изменениям и упрощая рефакторинг.
3. Повторное использование: Компоненты являются независимыми объектами и могут быть повторно использованы в различных контекстах и классах, способствуя принципу DRY (Don't Repeat Yourself) и уменьшая дублирование кода.
4. Улучшенная тестируемость: Поскольку компоненты слабо связаны и могут быть легко заменены, их проще мокировать (заменять тестовыми заглушками) и тестировать изолированно, что значительно упрощает юнит-тестирование.

Недостатки композиции:

1. Делегирование и "boilerplate"-код: Для доступа к методам компонента из внешнего класса часто требуется явное делегирование (перенаправление вызовов), что может приводить к написанию большего количества "шаблонного" (boilerplate) кода, особенно если нужно делегировать много методов.
2. Сложность при глубоких структурах: При очень глубокой или сложной композиции может быть трудно отслеживать, какие компоненты используются, как они взаимодействуют и как данные передаются между ними, что потенциально усложняет понимание общей архитектуры.

Пример композиции:

Представим автомобиль, который "имеет" двигатель. Car не является Engine, но использует его функциональность.

class Engine:
    def start(self):
        return "Двигатель запущен."

    def stop(self):
        return "Двигатель остановлен."

class Car:
    def __init__(self, engine: Engine):
        # Композиция: Car "имеет" Engine как свой компонент
        self.engine = engine

    def start_car(self):
        print("Автомобиль пытается завестись...")
        return self.engine.start() # Делегирование вызова компоненту

    def stop_car(self):
        print("Автомобиль пытается остановиться...")
        return self.engine.stop()

# Использование
my_engine = Engine()
my_car = Car(my_engine) # Передаем экземпляр Engine в Car
print(my_car.start_car())
print(my_car.stop_car())

# Преимущество гибкости: можно легко заменить тип двигателя, если Car будет принимать его через сеттер или в конструкторе
# class ElectricEngine:
#     def start(self): return "Электродвигатель запущен."
#     def stop(self): return "Электродвигатель остановлен."
# my_electric_car = Car(ElectricEngine())
# print(my_electric_car.start_car())

В этом примере класс Car не наследует функциональность Engine, а использует его как составную часть, делегируя ему операции запуска и остановки. Это позволяет Car быть независимым от конкретной реализации Engine.