Состав против делегирования

Термин «композиция» обычно используется в терминах объектного моделирования как выражение отношения «имеет-а» и является формой ассоциации (еще одна форма агрегации). Это обычно противопоставляется «наследованию» («является» отношением). Так:

В чем разница между композицией и агрегацией? Композиция подразумевает, что потомок не может существовать без контекста родителя.

Например, в доме есть одна или несколько комнат. Это композиционные отношения. Удали дом и комнаты тоже перестанут существовать. Дом также имеет ряд обитателей, являющихся экземплярами Person. Это отношение агрегации, потому что эти люди существуют вне контекста этого дома.

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

Вы заметите, что и A, и B из вашего примера имеют один и тот же внешний интерфейс. Чаще всего делают что-то вроде этого:

// this represents an interface
class A {
public:
  virtual void printStructure() = 0;
}

с конкретными классами:

class ConcreteA : A {
public:
  virtual void printStructure() { ... }
}

и

class DelegateA : A {
public:
  DelegateA(A& a) { this.a = a; }
  virtual void printStructure() { a.printStructure(); }
private:
  A a;
}

Извините за мои, вероятно, синтаксические ошибки C++. Я немного ржавый.

Я вижу пару отличий:

• Делегирование включает методы реэкспорта; в композиционном отношении методы внутренних объектов могут использоваться только в частном порядке и не раскрываться повторно.
• Композиция обычно подразумевает какую-то семантику владения с последствиями для жизненного цикла объекта; родительский объект «владеет» дочерним, а у дочернего нет особых причин существовать самостоятельно. Делегирование не имеет такого значения.

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

Композиция связана с отношениями между объектами.

Делегирование — это передача работы от одного объекта к другому.

На самом деле это разные (но иногда связанные) проблемы.

У вас есть B, составленный из A (B относится к A). B также делегирует один из своих методов A.

Но так как использование B пользователем A является частным (полностью инкапсулированным в черном ящике B), я бы не назвал использование B A «композицией». Я бы использовал «композицию» только в том случае, если к классу A можно было бы получить доступ из B. Здесь важно, если логическая модель B «имеет» A.

В вашем случае B реализован с точки зрения A. Поскольку это проблема реализации, ее можно рассматривать как не часть логической модели B. То есть вы можете разумно говорить о Б, не говоря и не заботясь об А.

Тем не менее, этот материал действительно важен только для инструментов моделирования PHB и UML. Или, возможно, если вы изучаете шаблоны проектирования. Я бы не стал слишком зацикливаться на этом.

[PHB => Островолосый босс]