Architecture événementielle en Swift : transformez votre code en orchestre d'événements

Pourquoi votre application Swift a-t-elle besoin d'une architecture événementielle ?

Imaginez que vous êtes le chef d'orchestre. Chaque musicien attend sa partition pour entrer au bon moment. Si les violonistes jouaient tous en même temps, ce serait le chaos. C'est à peu près ainsi que fonctionne l'architecture événementielle en Swift : chaque module ne réagit qu'à certains événements, sans tirer directement sur les ficelles des autres modules.

Lorsque j'ai rencontré pour la première fois la programmation orientée événements en Swift dans un projet commercial, j'ai réalisé à quel point c'était un outil puissant. Une application de livraison de repas : l'utilisateur appuie sur le bouton « Commander » — c'est un événement. Le panier se met à jour — événement. Un push arrive avec le livreur — événement. Chaque module (UI, réseau, BDD locale) s'abonne simplement aux événements nécessaires et fonctionne de manière indépendante. C'est cela, l'architecture événementielle.

Dans cet article, nous allons examiner trois approches pour implémenter l'architecture événementielle en Swift : les délégués classiques, NotificationCenter et un bus d'événements personnalisé. Vous verrez du code réel, comprendrez quand utiliser quoi, et pourrez l'appliquer immédiatement dans votre projet. C'est parti !

Fondamentaux de l'approche événementielle en Swift

Qu'est-ce qu'un événement dans le contexte de Swift ?

Un événement est un signal indiquant que quelque chose s'est produit. Cela peut être :

• Une entrée utilisateur (bouton pressé, texte modifié)
• Un changement de données (données reçues du serveur, BDD mise à jour)
• Des notifications système (l'application passe en arrière-plan, le clavier apparaît)

Le principe principal de l'architecture événementielle en Swift est le couplage faible (loose coupling). L'émetteur de l'événement ne sait pas qui le traitera. Le récepteur ne sait pas qui l'a émis. Ils communiquent via un bus d'événements — cela rend le code flexible et testable.

Le patron Observer — le fondement des événements

Le patron Observer en Swift est à la base de tout système événementiel. Nous avons un objet éditeur (Publisher) et plusieurs abonnés (Subscribers). Lorsque l'éditeur change d'état, il notifie tous les abonnés.

Swift dispose de plusieurs mécanismes intégrés pour cela :

• NotificationCenter — le bus d'événements global du SDK iOS
• Les délégués — un-à-un, mais avec contrôle
• Combine — le framework réactif d'Apple (iOS 13+)
• Des implémentations personnalisées — contrôle total du comportement

Examinons chaque approche avec des exemples.

Méthode 1. Les délégués : un grand classique

Les délégués en Swift sont la manière la plus simple d'implémenter un événement. Ils conviennent aux relations « un-à-un », lorsqu'un objet informe un autre de son état.

Exemple : imaginez que nous ayons un chargeur d'images qui doit notifier le contrôleur de la fin du chargement.

// 1. Définir le protocole déléguéprotocol ImageLoaderDelegate: AnyObject {    func imageLoader(_ loader: ImageLoader, didLoad image: UIImage)    func imageLoader(_ loader: ImageLoader, didFailWith error: Error)}

// 2. Classe éditeurclass ImageLoader {    weak var delegate: ImageLoaderDelegate?

    func loadImage(from url: URL) {        URLSession.shared.dataTask(with: url) { [weak self] data, _, error in            DispatchQueue.main.async {                if let error = error {                    self?.delegate?.imageLoader(self!, didFailWith: error)                } else if let data = data, let image = UIImage(data: data) {                    self?.delegate?.imageLoader(self!, didLoad: image)                }            }        }.resume()    }}

// 3. Contrôleur abonnéclass ViewController: UIViewController, ImageLoaderDelegate {    let loader = ImageLoader()    @IBOutlet weak var imageView: UIImageView!

    override func viewDidLoad() {        super.viewDidLoad()        lo