différence entre la déclaration des protocoles sur l'interface publique et l'interface privée / file d'implémentation

Lorsque vous ajoutez les protocoles au file .h, cela indique à tous ceux qui incluent le file d'en-tête auquel la class adhère aux protocoles donnés.

Lorsque vous ajoutez les protocoles au file .m, il s'agit essentiellement d'une indication privée que la class adhère aux protocoles. Seule l'implémentation sait.

Vous devez utiliser uniquement le premier formulaire (dans le file .h) lorsque les classs en dehors doivent savoir que la class adhère au protocole. Vous devez utiliser le second formulaire (dans le file .m) lorsque seule l'implémentation s'en soucie.

Dans l'exemple que vous avez donné, il est hautement improbable que d'autres classs sachent que la class adhère aux protocoles de vue de table. Ceux-ci devraient être dans le file. Il est également peu probable que les autres classs connaissent les protocoles de search. Ce sont des détails d'implémentation. Ceux-ci appartiennent au file .m.

Il peut y avoir des cas où vous utilisez les deux. C'est bon.

Voici ma ligne direcsortingce. Placez-le dans le file .m à less que vous ayez spécifiquement besoin de faire savoir aux autres classs l'utilisation du protocole.

Sauf erreur de ma part, il n'est pas possible d'utiliser la déclaration forward @protocol Foo; si vous déclarez également que votre class adopte le protocole.

Ce qui signifie que dans le file d'en-tête de votre class, vous devez inclure / importer un autre file d'en-tête avec la déclaration de protocole. Selon la taille et la complexité d'un projet, cela peut conduire à un file d'en-tête "enfer de dépendance".

Que ce soit ou non un réel danger doit être jugé par le projet réel. La plupart du time, ce n'est probablement pas quelque chose dont vous devez vous soucier, mais je voulais juste mentionner cet angle.

J'avoue que ça ne peut pas être une question de style !!!

Pourquoi cacher ces protocoles en .m, peut-être que vos classs iront avec des frameworks. Il est visible et tout le monde peut voir "Oh yaaa, ce sont les protocoles de delegates pour cette class". Au lieu de la magie cachée.

Donc, il est rendu transparent plutôt qu'opac.

Je juge préférable la première façon, de sorte que qui utilise la class sait si la class implémente un certain protocole. Cela ne peut être qu'un avantage.

Les protocoles sont utilisés pour garantir que certaines methods sont implémentées, c'est une alternative à l'inheritance multiple qui n'est pas possible en Objective-C. Supposons que je souhaite passer un object conforme à un protocole à une fonction ou une méthode, et je dois être sûr que cette class implémente un certain protocole. Dans ce cas, je dois savoir quels protocoles sont implémentés par la class .

Il arrête également un avertissement du compilateur à des fonctions (ou methods) comme celles-ci:

 void foo(id< SomeProtocol> obj) {...} 

La transparence est souvent une bonne idée et rarement un inconvénient.