Ответ.

Делегирование ответственности через композицию — это программная практика, при которой объект класса содержит объект другого класса (или классов) и использует их для реализации части своей логики, вместо того чтобы наследовать их интерфейс.

История вопроса

Ранние версии ООП делали упор на наследование, но со временем практика показала: композиция зачастую обеспечивает большую гибкость, расширяемость и снижение связанности между компонентами.

Проблема

Наследование связывает объекты жёстко: изменения в базовом классе затрагивают все наследники, иерархии становятся сложными, возникает хрупкость архитектуры. Композиция снимает эти проблемы, позволяет строить более надёжные и поддерживаемые системы.

Решение

В C++ делегирование реализуется через включение объекта одного класса как члена другого класса. В классе-обёртке вызываются методы вложенного объекта.

Пример кода:

class Logger {
public:
    void log(const std::string& msg) {
        std::cout << msg << std::endl;
    }
};

class FileProcessor {
    Logger logger; // Композиция
public:
    void process(const std::string& filename) {
        logger.log("Processing file: " + filename);
        // ...
    }
};

Ключевые особенности:

Более слабая связанность, гибкость
Возможность менять делегируемый объект на лету
Легче тестировать и сопровождать

Вопросы с подвохом.

Может ли композиция полностью заменить наследование?

Нет, наследование нужно там, где требуется отношение "является" (is-a), композиция — когда "имеет" (has-a). Например, Button наследует Widget, но Car "имеет" Engine (композиция).

Можно ли в композиции изменить поведение делегируемого метода?

Да, методы делегирования можно адаптировать, не трогая исходный класс. Также можно менять делегируемый объект динамически (например, через указатель или уникальный указатель).

Является ли композиция медленнее наследования?

Нет, разницы в производительности в большинстве случаев нет. Иногда наследование добавляет расходы за счёт виртуальных вызовов (vtable), а композиция — только размер объекта.

Типовые ошибки и анти-паттерны

Использование наследования там, где достаточно композиции
Переусложнение композиции вложенными объектами без нужды
"Раздувание" классов множеством фрагментированных зависимостей

Пример из жизни

Негативный кейс

В проекте все диалоговые окна наследовали общий DialogWindow. Добавление новой бизнес-логики приводило к неработающему коду во всех наследниках.

Плюсы:

Быстрое создание на старте
Повторное использование кода

Минусы:

Жёсткая структура
Любое изменение затрагивает всё дерево

Позитивный кейс

Общие функции вынесены в отдельные классы (логирование, валидация), которые внедряются в каждый диалог через композицию.