Mettre toutes les notifications dans un objet détruit l'encapsulation et c'est mauvais. Vous faites en sorte que les opérations de notification d'objets dépendent d'un autre objet qui fonctionne correctement. Ce sera en réalité un cauchemar qui suivra tout cela. Il est également rétrograde à l'objectif global des notifications, à savoir créer un système de messagerie décentralisé et modulaire.
Notifications ne doit pas être « parsèment le code », mais ils doivent être gérés uniquement par les objets qui les reçoivent. Si vous utilisez beaucoup de notifications, vous devrez peut-être créer une classe avec des méthodes dédiées pour gérer plusieurs notifications, puis hériter de vos autres classes de cette classe. De cette façon, vous obtenez une gestion automatique. L'une des grandes erreurs que les gens font avec les notifications est qu'ils enregistrent les contrôleurs quand ils ont vraiment besoin d'enregistrer leur modèle de données. Par exemple, supposons que vous téléchargiez des données à partir d'une URL et que vous souhaitiez mettre à jour l'interface à mesure qu'elle progresse et/ou lorsqu'elle se termine. Si vous avez plusieurs vues dans votre interface utilisateur et que vous enregistrez des contrôleurs, chaque vue doit gérer une notification (dont il peut y en avoir plusieurs). Toutefois, si vous configurez le modèle de données partagé pour recevoir la notification, vous n'avez besoin que maximum de deux notifications. On ira au datamodel pour que le datamodel puisse se mettre à jour et que le datamodel émette une notification générique pour que les vues d'écoute se mettent à jour depuis le datamodel. Rendre votre contrôleur de vue dépendant du modèle de données simplifie grandement la conception dans tous les cas.
excellente réponse merci! – ennuikiller