Observer Pattern

Also Known As

TL;DR

Explanation

The Observer (or Event/Listener) pattern decouples the subject (event emitter) from its observers (listeners). Observers register interest with the subject; when the subject's state changes, it notifies all registered observers without knowing their concrete types. In PHP frameworks, this is implemented as event dispatchers (Symfony EventDispatcher, Laravel Events). It is ideal for cross-cutting concerns like logging, cache invalidation, and email notifications that shouldn't pollute domain logic. Avoid overuse — complex event chains are hard to trace and debug.

Common Misconception

Why It Matters

Common Mistakes

• Not removing observers when they are no longer needed — memory leaks in long-running processes.
• Observers that throw exceptions crashing the event dispatch loop — catch inside the observer or the dispatcher.
• Synchronous observers performing slow operations (email, HTTP calls) — use async dispatch for heavy work.
• Circular event chains where an observer triggers an event that re-triggers the same observer.

Avoid When

• The event chain is hard to follow — deeply nested observers triggering other observers cause debugging nightmares.
• Observers are synchronous and slow — a single slow listener blocks all subsequent listeners and the original caller.
• The order of observer execution matters and is not guaranteed — use an ordered pipeline instead.
• You only have one listener — a direct method call is simpler and equally clear.

When To Use

• Decoupling a publisher from multiple independent consumers that react to the same event.
• Plugin or extension systems where third-party code needs to hook into core events.
• Audit logging, cache invalidation, and notifications that should not be in the core business logic.
• UI frameworks and event-driven architectures where components react to state changes.

Code Examples

// Direct method calls — tight coupling:
class OrderService {
    public function place(Order $o): void {
        $this->save($o);
        $this->emailService->sendConfirmation($o); // Coupled
        $this->inventoryService->reserve($o);       // Coupled
        $this->analyticsService->track($o);         // Coupled
    }
}
// Better: dispatch OrderPlaced event; each service subscribes independently

interface EventListener {
    public function handle(object $event): void;
}

class EventDispatcher {
    private array $listeners = [];

    public function listen(string $event, EventListener $listener): void {
        $this->listeners[$event][] = $listener;
    }
    public function dispatch(object $event): void {
        foreach ($this->listeners[$event::class] ?? [] as $listener) {
            $listener->handle($event);
        }
    }
}

// Usage
$dispatcher->listen(OrderPlaced::class, new SendConfirmationEmail());
$dispatcher->listen(OrderPlaced::class, new UpdateInventory());
$dispatcher->dispatch(new OrderPlaced($order));

References

• ↗ https://refactoring.guru/design-patterns/observer

Tags

Related Terms