Quand et quelles méthodes doivent être déclarées dans la section @interface d'une classe? Si je comprends bien, des méthodes décrivant ce que votre classe doit être déclarée dans la section @interface , mais d'autres méthodes "assistant" ne doivent pas être déclarées. Est-ce une compréhension correcte de mon côté?
3 Réponses :
Un moyen est de déclarer les méthodes d'instance Par exemple, dans et, à l'intérieur de votre fichier dans .h fichier. Et, déclarez les méthodes privées à l'intérieur du .m , à l'aide d'une catégorie . MyownClass.h < / code> fichier. myowllass.m fichier, avant le bloc @Implementatation / p>
NB Le compilateur ne vérifie pas si les méthodes déclarées dans une catégorie sont en réalité implémentées. Vous pouvez également utiliser une extension de classe, qui ressemble à une catégorie anonyme, sauf que les méthodes qu'il déclarent doivent être implémentées dans le bloc principal @Implementatation .
Étant donné que l'idée d'EXTLETACTACT est de créer la catégorie dans la mise en œuvre, comme moyen pratique de faire des méthodes privées, alors vous devriez probablement toujours utiliser l'extension comme Albertamg suggère: @interface myownClass () ... il y a Aucun avantage d'être capable de sauter éventuellement de sauter des méthodes dans la catégorie depuis son utilisation uniquement dans votre classe.
Vous devez déclarer toutes vos méthodes dans votre .h La pointe de vide est agréable mais c'est juste un pourboire. Si vous n'avez pas l'intention d'expédier votre binaire en tant que SDK, vous n'en avez pas vraiment besoin.
Objective-C n'a pas (encore) méthodes privées.
"Si vous n'avez pas l'intention d'expédier votre binaire en tant que SDK, vous n'en avez pas vraiment besoin". Quoi?!
Eh bien, de Wikipedia: "Un kit de développement de logiciels (SDK ou" Devkit ") est généralement un ensemble d'outils de développement permettant de créer des applications pour un ensemble logiciel, cadre logiciel, plate-forme matérielle, système informatique, ..., système d'exploitation ou plate-forme similaire. " Donc, je ne pense pas que ce soit le meilleur terme à utiliser ici. En dehors de cela, juste parce que vous savez qu'une méthode existe, ce n'est pas privé. Vous n'avez pas besoin d'une implémentation compilée pour cacher des choses. Lorsque nous parlons de méthodes privées, d'encapsulation, ..., c'est du point de vue des objets, pas nécessairement du programmeur.
J'utilise souvent la pointe que @ptystack fourni.
Si vous souhaitez publier une application de votre application en tant que bibliothèque statique pour activer les autres programmeurs d'utiliser vos services (qui semble adapter la définition du SDK), vous pouvez vouloir que certaines méthodes ne soient pas visibles (du point de vue du programmeur). Comme objectif-C n'offre pas une capacité de méthodes privées, il n'y a aucun avantage à utiliser des "catégories privées", du point de vue des objets (comme expliqué par Raphael).
Un SDK est bien plus qu'une bibliothèque :-) Mais je vois le point. Je suis d'accord avec vous jusqu'à la dernière phrase. Il sont quelques avantages. Par exemple, dites que vous avez plusieurs méthodes qui effectuent des tâches similaires dans votre interface. Il existe-t-il une raison de ne pas créer une seule méthode responsable d'une tâche commune dans une mode privée et appelez-la de la mise en œuvre des méthodes exposées?
Un SDK est bien plus qu'une bibliothèque, oui. Dans mon esprit, j'ai surtout un SDK commercial où vous devez expédier un binaire. À propos de créer une méthode privée pour les tâches sous-jacentes communes à plusieurs méthodes, oui c'est une bonne pratique, mais elle est inutile dans l'objectif-C comme: "Objective-C n'a pas (encore) méthodes privées." (moi-même, il y a deux heures). C'est bien, mais inutile. Il n'ajoute aucune fonctionnalité à déclarer toutes les méthodes de votre .h
édité. Merci pour votre honnêteté. Je vais aussi supprimer ce commentaire aussi.
Vous devez généralement ajouter vos méthodes au fichier .h lorsque vous souhaitez qu'une classe externe ait accès à celle-ci (méthodes publiques).
Quand ils sont privés (utilisés uniquement en interne par la classe), il suffit de les mettre dans votre fichier .m.
Quoi qu'il en soit, c'est juste un motif. Comme objectif-c fonctionne avec des messages, même si vous ne définissez pas de méthode dans votre fichier .h, un fichier externe peut y accéder, mais au moins votre auto-complet ne le montrera pas.