Composite - дерево об'єктів

Composite дозволяє працювати з деревом об'єктів так само, як з одним об'єктом: і окремий "лист", і "гілка" (група) реалізують той самий інтерфейс.

Яку проблему вирішує

Ієрархічні структури (меню з підменю, дерева категорій, кошик із бандлами) змушують клієнтський код постійно розрізняти "це одиничний елемент чи група?" і писати окремі гілки для кожного випадку та ручну рекурсію обходу.

Як вирішує

І лист, і композит реалізують спільний інтерфейс. Композит зберігає дітей (які теж можуть бути композитами) і делегує виклик їм. Клієнт викликає той самий метод незалежно від рівня вкладеності - рекурсія прихована в самих об'єктах.

У прикладі нижче і окремий товар (ProductItem), і набір товарів (Bundle) вміють рахувати total(). Бандл рахує суму своїх дітей, які теж можуть бути бандлами - глибина дерева не обмежена.

interface CartItem
{
  public function total(): int;
}

class ProductItem implements CartItem
{
  public function __construct(private int $price) {}

  public function total(): int
  {
    return $this->price;
  }
}

class Bundle implements CartItem
{
  private array $items = [];

  public function add(CartItem $item): void
  {
    $this->items[] = $item;
  }

  public function total(): int
  {
    return array_sum(array_map(
      fn (CartItem $item) => $item->total(),
      $this->items
    ));
  }
}

Де застосовувати

• Деревоподібні структури: меню та підменю, дерева категорій, вкладені права доступу, кошик із бандлами, UI-компоненти.
• Скрізь, де хочеться однакової логіки для одиничного елемента і групи.

Плюси та мінуси

• + Клієнтський код не відрізняє лист від групи - логіка однакова на всіх рівнях.
• + Нові типи елементів додаються без змін у клієнті.
• − Спільний інтерфейс інколи доводиться "розмивати" (методи додавання дітей не мають сенсу для листа).
• − Надлишковий, якщо структура завжди пласка - вистачить звичайної колекції.