---
title: "Observer - реакція на події"
url: https://laravelukraine.com/blog/observer-reakciia-na-podiyi
author: "Олексій Бабінцев"
date: 2026-07-27
---

# Observer - реакція на події

Observer організовує реакції на події без жорстких зв'язків: об'єкт сповіщає підписників про зміну, не знаючи, хто вони.

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

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

### Як вирішує

Об'єкт лише публікує подію про факт. Слухачі підписуються на неї й виконують побічні дії незалежно. Нову реакцію додаєш новим слухачем, не торкаючись джерела події. У Laravel це Events, Listeners і Subscribers.

```php
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);
```

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

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

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

- **+** Нові реакції додаються без змін у вихідній логіці; контролер лишається тонким.
- **+** Події легко фейкати в тестах і перевіряти їх відправку.
- **−** Прихований потік керування: за подією важко простежити, що саме виконається.
- **−** Важких слухачів треба відправляти у чергу, інакше вони сповільнять основний запит.