Observer організовує реакції на події без жорстких зв'язків: об'єкт сповіщає підписників про зміну, не знаючи, хто вони.
Яку проблему вирішує
Коли на одну дію (оплата замовлення) треба навісити кілька побічних реакцій (лист, вебхук, аналітика), вшивання їх прямо в код дії робить його громіздким і прив'язаним до конкретних реакцій. Додати нову - означає правити вихідну логіку.
Як вирішує
Об'єкт лише публікує подію про факт. Слухачі підписуються на неї й виконують побічні дії незалежно. Нову реакцію додаєш новим слухачем, не торкаючись джерела події. У Laravel це Events, Listeners і Subscribers.
class OrderPaid
{
public function __construct(public Order $order) {}
}
class SendReceipt
{
// У Laravel 11+ слухач автоматично знаходиться за типом аргументу handle().
public function handle(OrderPaid $event): void
{
Mail::to($event->order->email)->send(new ReceiptMail($event->order));
}
}
// Диспатч події (хелпер event() або статичний метод OrderPaid::dispatch()):
event(new OrderPaid($order));
// Явна реєстрація, якщо авто-discovery вимкнено:
Event::listen(OrderPaid::class, SendReceipt::class);
// У тестах події легко фейкати:
Event::fake();
event(new OrderPaid($order));
Event::assertDispatched(OrderPaid::class);
Де застосовувати
- Логування, нотифікації, вебхуки, аналітика - усе, що є реакцією на доменний факт.
- Коли реакцій багато і вони можуть з'являтися чи зникати незалежно.
Плюси та мінуси
- + Нові реакції додаються без змін у вихідній логіці; контролер лишається тонким.
- + Події легко фейкати в тестах і перевіряти їх відправку.
- − Прихований потік керування: за подією важко простежити, що саме виконається.
- − Важких слухачів треба відправляти у чергу, інакше вони сповільнять основний запит.
