Quelle est la meilleure approche de la pratique des méthodes privées dans l'objectif-c. C'est une méthode qui va seulement être utilisée la classe comme méthode d'assistance.
En particulier ce qui n'est pas clair pour moi est:
merci
3 Réponses :
Ce que vous voulez probablement utiliser s'appelle "Extensions de classe". Ils ont l'air similaire, mais ne devraient pas être confondus avec des catégories. Cela vous permettra de déclarer des méthodes privées dans votre fichier .m et vous obtiendrez toutes les belles corrections et suggestions IDE.
Voici un article décent sur celui-ci
et une question associée à la question
Celles-ci ne semblent pas couvrir la possibilité de simplement mettre en œuvre une méthode dans la «mise en œuvre» / *. m Fichier et l'utiliser à l'intérieur - Y a-t-il quelque chose de mal à faire cela?
@Greg: il n'y a rien de mal à cela que de définir une fonction en C sans le déclarer quelque part d'abord. Il y a la même commande WTF dans le fichier source et telle aussi.
@Greg ça va travailler aussi, réalisez simplement que vous avez des problèmes de commande. Vous obtiendrez toujours un avertissement si la mise en œuvre est après une utilisation dans la source, par exemple. Utilisez une extension pour presque tout interne - facilite la prise de vue unique d'examiner l'inventaire de la mise en œuvre.
@Anomie - Heh, tu voulais dire "WRT"? Je ne sais pas comment WTF s'applique à cette phrase ...
Hah, oui. Je modifierais le commentaire, mais pour une raison quelconque, cela ne me laissera pas.
Il n'est pas nécessaire de spécifier la méthode dans le fichier d'en-tête public. Vous voudrez peut-être un fichier d'en-tête "privé" destiné à être utilisé par d'autres classes de votre module, si les classes de votre module sont censées être "amis". Vous pouvez même avoir un fichier d'en-tête "protégé", comme le fait Apple avec Une méthode privée dans l'objectif-c n'est qu'une personne qui n'est pas documentée publiquement; Toute méthode peut toujours être appelée de n'importe où, tant que l'appelant le connaît le nom afin de créer le sélecteur approprié. L'avantage de ne pas documenter publiquement une méthode est que vous êtes libre de changer ou de le supprimer sans vous soucier de la compatibilité en arrière. Les quitter du fichier d'en-tête est une façon de ne pas les documenter publiquement. uigesturerecognizersubclass.h par exemple. C'est tout simplement convention, cependant, rien de soutenu par la langue elle-même.
Pas d'argument avec votre réponse - c'est techniquement correct. Cependant, omettez simplement une déclaration de l'ancienne façon de faire des choses. L'utilisation d'une extension de classe pour déclarer votre méthode à l'intérieur du fichier de mise en œuvre est vraiment la nouvelle meilleure pratique pour la gestion de cela dans l'objectif C 2.0. Je veux juste m'assurer que les gens lisent cette prise en charge. À votre santé.
Meilleure pratique (et même une option de compilateur à vérifier) est que toutes les méthodes sont déclarées d'une manière ou d'une autre. Pour «masquer» les méthodes d'assistant à partir des yeux indiscrets, déclarez-la comme tel dans le fichier de mise en œuvre .m, comme dans: et ainsi de suite. Les méthodes privées sont une catégorie appelée private de méthodes de myClass. Cette catégorie peut être déclarée n'importe où, même dans un fichier maître .h appelé des méthodes privées, bien que ce soit un cauchemar de maintenance. Ainsi, en utilisant le fichier public .h pour les méthodes publiques et le fichier .m pour déclarer des méthodes privées, vous avez toutes vos méthodes déclarées quelque part. J'utilise cette option de compilateur pour m'assurer et le forcer, de sorte que toute méthode utilisée est réellement déclarée quelque part (ou que je reçois une erreur de syntaxe) et que je ne reçois pas de collisions d'exécution en raison de la méthode non trouvée.
Rappelez-vous simplement qu'il n'y a pas de méthode «privée», dans la mesure où il ne pouvait pas être appelé d'autres classes. Mettre dans une catégorie Obfuscates L'existence de la méthode, mais si votre classe implémente une méthode, elle y répondra.
Oh ... Ok .... Est-ce que la plupart des gens se préoccupent toujours d'essayer de les marquer comme privés alors, ou simplement faire le public et les énumérer dans le fichier * .h avec de vraies méthodes publiques
Si vous souhaitez présenter des utilisateurs une interface claire, vous ne devez pas énumérer des méthodes dans l'en-tête que vous ne souhaitez pas qu'ils utilisent. Toutefois, si vous ne les déclarez pas dans une extension de classe (voir ma réponse), vous perdrez toutes les Nexéties de la vérification de la syntaxe du compilateur. La réponse d'Anomie va bien, mais c'est la façon de faire des choses. Les extensions de classe sont la nouvelle façon «Objective C» de l'accomplir.