Comment fonctionnent les événements et les auditeurs ?

Question

Accepted Answer

Les **événements et auditeurs** de Laravel implémentent le pattern observateur — vous **dispatchez un événement** quand quelque chose de notable se produit, et un ou plusieurs **auditeurs** y réagissent. Cela découple le code : la source de l'événement n'a pas besoin de savoir qui répond, ce qui permet une séparation claire des préoccupations.

## Définir un événement et un auditeur

```php
// the event — a simple data carrier for "something happened"
class OrderShipped {
    public function __construct(public Order $order) {}
}

// a listener — reacts to the event
class SendShipmentNotification {
    public function handle(OrderShipped $event): void {
        Mail::to($event->order->customer)->send(new ShipmentMail($event->order));
    }
}
// generate with: php artisan make:event / make:listener
```

## Dispatcher l'événement

```php
// when the order ships, DISPATCH the event — all listeners run
OrderShipped::dispatch($order);
// or: event(new OrderShipped($order));
```

Le dispatch de l'événement déclenche tous ses auditeurs enregistrés. Le code d'expédition de commandes annonce simplement ce qui s'est passé — il ne sait pas (et ne se soucie pas) que des emails, des analyses, ou d'autres réactions se produisent.

## Plusieurs auditeurs pour un événement (découplage)

```php
// one event can have MANY listeners — each a separate concern
OrderShipped → SendShipmentNotification    // email
            → UpdateInventory               // adjust stock
            → RecordAnalytics               // log the event
// add reactions without modifying the order-shipping code
```

C'est l'avantage clé : vous pouvez ajouter de nouvelles réactions (un auditeur) à un événement sans modifier le code qui le dispatch — un découplage propre et extensible.

## Auditeurs en file d'attente (async)

```php
class SendShipmentNotification implements ShouldQueue {   // run the listener in the BACKGROUND
    public function handle(OrderShipped $event): void { ... }
}
```

L'implémentation de `ShouldQueue` fait fonctionner un auditeur **de manière asynchrone** via la file d'attente — ainsi les réactions lentes (envoi d'email) ne retardent pas la réponse.

## Pourquoi c'est important

Les événements et auditeurs sont une fonctionnalité utile de Laravel pour **découpler** le code — permettant à différentes parties d'une application de réagir à des occurrences sans couplage étroit, ce qui est précieux pour les réactions transversales et pour maintenir le code maintenable.

Comprendre comment ils fonctionnent est utile à la fois pour les utiliser et pour les reconnaître dans les bases de code : le pattern vous permet de dispatcher un événement quand quelque chose de significatif se produit (une commande est expédiée, un utilisateur s'inscrit) et d'avoir plusieurs auditeurs indépendants réagissent (envoyer un email, mettre à jour l'inventaire, enregistrer les analyses), chacun gérant une préoccupation séparée.

L'avantage clé est l'**extensibilité par découplage** — vous pouvez ajouter de nouvelles réactions en enregistrant un auditeur sans modifier le code qui dispatche l'événement, en gardant les préoccupations séparées et le code de dispatch focalisé.

La capacité à rendre les auditeurs **en file d'attente** (`ShouldQueue`) afin qu'ils s'exécutent de manière asynchrone est également importante, permettant aux réactions lentes (emails, appels d'API externes) de se produire en arrière-plan sans retarder la réponse de l'utilisateur.

Savoir comment fonctionnent les événements/auditeurs, leur avantage de découplage, et les auditeurs en file d'attente pour le traitement asynchrone est une connaissance précieuse pour construire des applications Laravel bien structurées et extensibles. (Comme avec les signaux dans d'autres frameworks, la mise en garde est que les événements créent un comportement implicite, action-à-distance qui peut être plus difficile à tracer — donc ils sont mieux utilisés pour un vrai découplage transversal plutôt que comme défaut pour toute la logique post-action, où le code explicite est souvent plus clair.)