Je ne suis pas sûr de ma terminologie ici, mais:
J'ai une zone de vue dans une application iPhone qui doit être un délégué pour deux autres objets (délégateurs). P>
est-ce possible ? Cela ne fonctionne pas: P>
@interface my_projectViewController : UIViewController <DelegatorOne> <DelegatorTwo> {
...
}
5 Réponses :
Votre syntaxe n'est pas tout à fait raison, mais il est très possible d'avoir un objet agir en tant que délégué pour plusieurs clients.
quelque chose comme: ... devrait fonctionner
Le pluriel approprié est délégués em> et oui, vous pouvez absolument que votre classe soit la déléguée pour différents protocoles. La syntaxe est cependant comme ceci: P> @interface MyViewController : UIViewController<UITextFieldDelegate,UIWebViewDelegate,UINavigationBarDelegate,UIActionSheetDelegate,URLDownloaderDelegate> {
}
Différence légèrement pédante mais importante: ce que vous fournissez dans votre question n'est pas un objet d'un délégué de plusieurs délégateurs, mais un objet se conformant à plusieurs protocoles. Dans la plupart des cas, un délégué aura un protocole associé à celui-ci (UactionheetDelegate, UitextFieldelegate), mais tous les délégués n'ont pas de protocoles, et tous les protocoles impliquent des délégués.
Dans un exemple très artificiel, vous pourriez avoir un objet qui vous déléguette Un autre objet qui se conforme à aucun protocole: Dans cet exemple, les instances d'objet s'attendent à une instance d'objetb comme leur "délégué", même si l'objetb n'est pas vraiment un protocole , mais une interface de classe! L'existence d'un objet en tant que délégué est plus un état d'esprit qu'une exigence stricte d'avoir un protocole - c'est juste que la plupart des développeurs (ok, presque tous) prendront les méthodes déléguées et les enfreignent dans un protocole afin que plusieurs objets peut devenir des délégués pour des instances d'objections, plutôt que d'exiger que le délégué soit une instance (ou une sous-classe) de Objectb. Cela supprime également le besoin d'objections de "savoir sur" objetb dans le sens de dans un exemple légèrement moins armé, un objet peut être conforme à un protocole sans être délégué. Pensez au protocole NScopiant comme un excellent exemple de cela - tout ce que le protocole indique que les objets qui implémentent peuvent être copiés à l'aide de la méthode de copie . Les gens ne considèrent pas à la fin, rappelez-vous simplement: Un protocole n'implique pas de délégué et un délégué ne signifie pas toujours (mais généralement) implique un Protocole . #import son fichier d'en-tête. copier une méthode "déléguée", car aucun objet ne va simplement dire [copie de délégué] sans faire quelque chose avec cette copie, donc des objets qui mettent en œuvre Nscoping ne sont pas vraiment "déléguer" objets.
Bien entendu, des protocoles informels sont généralement utilisés pour les délégués également, ce qui est lorsque vous ne faites pas explicitement les méthodes requises en tant que protocole, mais devraient connaître les noms de méthodes. UIKIT et APPLIT utilisent souvent des protocoles informels et disposent d'un comportement no-op si la classe ne prend pas en charge le message requis par le protocole.
ALBLUE: Bon point! Un exemple qui vous vient à l'esprit est NSXMLParser, qui n'a pas de protocole formel NSXMLParserDelegate correspondant, mais documente une poignée de analyseur: ...: méthodes.
En plus de ce qui a été dit sur la mise en œuvre de plusieurs protocoles de délégués, le modèle de délégation de cacao permet à un objet de devenir un délégué pour plusieurs objets du même type. C'est pourquoi la plupart des méthodes de délégation incluent un pointeur à l'objet appelant comme un paramètre, soit l'objet d'une NSNotification. Vous pouvez l'utiliser pour obtenir plus d'informations sur l'objet ou la comparer à une variable d'instance afin de déterminer quelles actions à prendre.
Je l'habitude d'utiliser l'approche délégué Multicast dans un de mes projets. Regardez Multicast Les délégués à Cocoa