Композиция строит поведение, содержа другие объекты (отношение "has-a") и делегируя им. Наследование получает поведение, расширяя класс ("is-a"). Совет "отдавайте предпочтение композиции" существует потому, что наследование создает тесную, хрупкую связь с базовым классом, в то время как композиция остается гибкой.
<T> <T> {
{ add(x); }
T { remove(size() - ); }
}
class Stack<T> {
private final List<T> items = new ArrayList<>(); // HAS-A list
void push(T x) { items.add(x); }
T pop() { return items.remove(items.size() - 1); }
// only push/pop are exposed → LIFO invariant is safe
}
Путем содержания списка вместо являния им, Stack раскрывает только те операции, которые хочет.
| Композиция | Наследование |
|---|---|
| Гибкая, замена частей во время выполнения | Фиксируется во время компиляции |
| Скрывает внутренние части (делегирование) | Наследует весь интерфейс |
| Больше проводки/шаблонного кода | Меньше кода, когда действительно is-a |
| Избегает хрупкого базового класса | Подкласс ломается при изменении базы |
Используйте наследование только для подлинных, стабильных отношений is-a; используйте композицию для "Мне нужно это поведение".
Наследование раскрывает весь интерфейс родителя, поэтому подкласс не может полностью контролировать собственный контракт — утечка Stack extends ArrayList — это классический пример.
Композиция сохраняет отношения явными и взаимозаменяемыми, вот почему внедрение зависимостей, паттерны стратегии и большинство гибких проектов на нее полагаются.