NSNotificationCenter vs délégation (à l'aide de protocoles)?
Quels sont les avantages et les inconvénients de chacun d'eux?
Où dois-je les utiliser spécifiquement?
La règle d'or ici est le nombre de clients qui souhaitent être informés d'un événement. S'il s'agit principalement d'un objet (par exemple, pour ignorer une vue ou pour agir sur un bouton cliqué, ou pour réagir à un téléchargement échoué), vous devez utiliser le modèle délégué.
Si l'événement que vous émettez peut intéresser de nombreux objets à la fois (par exemple, rotation de l'écran, utilisation de la mémoire, connexion/déconnexion utilisateur), vous devez utiliser le NSNotificationCenter.
Leurs objectifs sont différents:
La notification est utilisée pour diffuser des messages à plusieurs destinataires inconnus de l'expéditeur.
La délégation est utilisée pour envoyer des messages à un seul destinataire connu agissant au nom de l'expéditeur.
Les notifications sont généralement meilleures pour notifier l'interface utilisateur des modifications qui se produisent également sur d'autres threads. La documentation d'Apple décourage fortement l'utilisation de délégués sur les threads lorsque cela est possible, à la fois pour des raisons de stabilité et de performances. Sur Mac, ils suggèrent d'utiliser des liaisons, mais comme elles n'existent pas sur l'iPhone, les notifications sont probablement votre prochain meilleur pari.
Considérer les performances est une bonne idée (délégation meilleure pour un petit nombre d'objets notifiés, centre de notification meilleur pour un plus grand nombre d'objets, ou est-ce? Exécuter un profileur) mais je pense qu'un facteur plus important puisque vous parlez d'Objectif-C et moins susceptibles de parler des parties très hautes performances de votre base de code, qui sont susceptibles d'être écrites en C, réduit les dépendances au moment de la compilation entre les modules.
Rien ne vous empêche d'avoir un ensemble de délégués plutôt qu'un seul délégué.
Je peux utiliser NSNotificationCenter uniquement pour l'état des composants de pile réseau que je crée et des interfaces de surveillance d'état de périphérique personnalisées. Mais pour la plupart des couplages, et non pour le statut global de l'application, je pense qu'il est plus clair d'utiliser des contrats d'interface normaux dans Objective-C dans la plupart des cas et plus faciles à suivre pour les personnes qui vous suivent que d'utiliser NSNotificationCenter. En fait, je n'ai jamais utilisé NotificationCenter pour mes propres événements personnalisés et je préfère utiliser des délégués pour faciliter la compréhension du code par quelqu'un d'autre qui lit mon code.
Et enfin, bien sûr, avec les notifications vers/depuis l'API standard, vous n'avez pas le choix et vous devez utiliser l'une des deux méthodes Apple proscrire pour un événement donné.
Les notifications sont meilleures pour découpler les composants de l'interface utilisateur. Il vous permet de brancher n'importe quelle vue sans aucune modification dans vos contrôleurs ou modèles. Certainement mieux pour une conception à couplage lâche.
Mais pour la performance entre la délégation et la notification, vous devez penser à la fréquence de l'appel.
La délégation pourrait être meilleure pour les événements plus fréquents, les notifications sont meilleures pour les événements moins fréquents mais plus de destinataires. C'est à projeter quoi choisir.
Une option entre ces deux utilise le modèle d'observateur, sans NSNotificationCenter. Regardez mon implémentation Objective-C ici .