Dans le développement touche de cacao ...Comment organiser les fichiers délégués
que recommanderiez-vous?
Eh bien cela dépend. Le concept entier pour les protocoles de délégué existe de sorte que vous pouvez avoir beaucoup de flexibilité. Parfois, vous prenez la route par défaut simplement, mais parfois vous devez être en mesure d'avoir beaucoup de différentes classes de délégués.
(1) Délégué de l'application - le délégué de l'application ne doit être utilisé que pour les méthodes UIApplicationDelegateProtocol ou les délégués pour les propriétés réelles de l'instance déléguée elle-même. En d'autres termes, si le délégué de l'application ne traite pas directement une instance, par ex. l'objet application, le délégué de l'application doit alors servir de délégué de l'instance. Empiler des méthodes extranous dans le délégué de l'application embrouillera l'application et la rendra mutuellement interconnectée et difficile à déboguer et à maintenir. (2) Les classes déléguées entièrement séparées sont généralement utilisées lorsque vous avez (A) un grand nombre de protocoles délégués à implémenter ou (B) que vous avez le même protocole à implémenter pour plusieurs instances mais que vous avez besoin d'un comportement différent pour chaque objet déléguer. Par exemple. vous avez plusieurs UITextField dont chacun se comporte différemment. Vous créez en tant que classe de délégué distincte pour chacun de sorte que chaque champ de texte possède sa propre implémentation personnalisée des méthodes du protocole de délégué. (3) L'utilisation du contrôleur pour les délégués est la façon la plus simple, la plus logique et la plus modulaire de procéder dans la majorité des cas. Dans de nombreux cas, tels que les éléments d'interface utilisateur, les méthodes déléguées nécessitent une connaissance des autres éléments d'interface utilisateur que le contrôleur peut fournir. En résumé, ne faites jamais (1) comme place de parking générale pour des méthodes de délégués aléatoires et par défaut (3) dans la majorité des cas.