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