Modèle d’observateur

Le modèle Observer fait référence à des modèles de conception comportementale.
Le modèle permet d’envoyer un changement d’état d’un objet aux abonnés à l’aide d’une interface commune.
Disons que nous développons un messager pour les programmeurs, nous avons un écran de discussion dans l’application. Lorsque vous recevez un message avec le texte « problème » et « erreur » ou « quelque chose ne va pas », vous devez colorer l’écran de la liste d’erreurs et l’écran des paramètres en rouge.
Ensuite, je décrirai 2 options pour résoudre le problème, la première est simple mais extrêmement difficile à prendre en charge, et la seconde est beaucoup plus stable en termes de support, mais vous oblige à tourner la tête lors de la mise en œuvre initiale.

Bus commun

Toutes les implémentations du modèle contiennent l’envoi de messages lorsque les données changent, l’abonnement aux messages et un traitement ultérieur dans les méthodes. L’option de bus partagé contient un seul objet (généralement un singleton) qui distribue les messages aux destinataires.
La simplicité de mise en œuvre est la suivante :

  1. L’objet envoie un message abstrait au bus partagé
  2. Un autre objet abonné au bus partagé récupère le message et décide de le traiter ou non.

L’une des options d’implémentation disponibles auprès d’Apple (sous-système NSNotificationCenter), ajout d’une correspondance entre l’en-tête du message et le nom de la méthode appelée par le destinataire lors de la livraison.
Le plus gros inconvénient de cette approche – Si vous modifiez davantage le message, vous devrez d’abord vous souvenir, puis modifier manuellement tous les endroits où il est traité et envoyé. Il existe un cas de mise en œuvre initiale rapide, suivie d’un support long et complexe qui nécessite une base de connaissances pour un fonctionnement correct.

Délégué multidiffusion

Dans cette implémentation, nous créerons la classe déléguée multicast finale ; tout comme dans le cas d’un bus partagé, les objets peuvent s’y abonner pour recevoir des « messages » ou des « événements », mais le travail d’analyse et de filtrage des messages est non affecté aux objets. Au lieu de cela, les classes d’abonnés doivent implémenter les méthodes de multidiffusion du délégué avec lesquelles il les notifie.
Ceci est implémenté en utilisant des interfaces/protocoles délégués ; lorsque l’interface générale change, l’application ne sera plus construite, il sera alors nécessaire de refaire tous les emplacements de traitement d’un message donné, sans avoir besoin de maintenir une base de connaissances distincte. pour me souvenir de ces lieux. Le compilateur est votre ami.
Cette approche augmente la productivité de l’équipe, car il n’est pas nécessaire d’écrire ou de stocker de la documentation, il n’est pas nécessaire qu’un nouveau développeur essaie de comprendre comment un message et ses arguments sont traités, mais ils travaillent avec une interface pratique et compréhensible. , c’est ainsi qu’est implémenté le paradigme de la documentation par le code.
Le délégué de multidiffusion lui-même est basé sur le modèle de délégué, dont je parlerai dans le prochain article.

Sources

https://refactoring.gu/ru/design-patterns/observer