Quand est-ce que je définis les méthodes objective-c?

Question

Je suis en train d'apprendre Objective-C, et ont un C/C++ arrière-plan.

• En orienté objet C++, vous devez toujours déclarer votre méthode avant de définir (mettre en œuvre), même si elle est déclarée dans la classe parent.

• Dans le cadre de procédures de style C, IIRC, vous pouvez vous en sortir avec juste la définition d'une fonction aussi longtemps qu'il est seulement appelé à partir d'autre chose dans le même compilational unité (ie. le même fichier) qui est venu plus tard dans le fichier (bien, à condition de ne pas déclarer d'ailleurs avec "extern").

• Maintenant, en Objective-C, il semble que vous ne devez déclarer les sélecteurs dans le fichier d'en-tête si ils vont être utilisés par quelque chose d'extérieur, et que vous pouvez faire jusqu'sélecteurs dans votre .m dossier d'amende, et de les appeler dans le .m de fichier. Aussi, il semble que délégué méthodes ou les méthodes héritées ne sont jamais (re)définir.

Suis-je sur la bonne voie? Quand avez-vous besoin de définir un sélecteur en Objective-C?

Answer 1

Pour Objective-C méthodes, la pratique générale est de mettre les méthodes que vous souhaitez exposer dans l' @interface de la section de l'en-tête de fichier de sorte que les autres code peut contenir seulement le .h et de savoir comment interagir avec votre code. Basés sur la commande "paresseux déclaration" fonctionne exactement comme les fonctions en C - vous ne pas avoir à déclarer un prototype de méthode, sauf si vous avez une dépendance qui ne peut pas être réglé par la commande, mais vous pouvez ajouter des prototypes de méthode à l'intérieur de l' @implementation si nécessaire.

Donc, oui, vous êtes sur la bonne voie. Ne pas répéter la méthode de prototype pour les méthodes héritées - le compilateur trouve dans le parent du fichier d'en-tête. Délégué méthodes peuvent être définies comme des prototypes dans une catégorie (cloué sur une classe) et mis en place comme vous le souhaitez, mais le délégué n'a pas besoin de fournir un prototype de méthode, puisqu'il est déjà défini. (Il peut encore s'il veut, pour plus de clarté, etc.)

Puisque vous êtes seulement à apprendre Objective-C, le reste de cette réponse est beaucoup plus de détails que vous avez demandé. Vous avez été averti. ;-)

---

Lorsque vous de manière statique type d'une variable (par exemple, MyClass* au lieu de id), le compilateur vous avertir lorsque vous essayez d'appeler une méthode d'une classe ne fait pas de publicité qu'elle met en œuvre, si elle fait ou non. Si vous dynamiquement le type de la variable, le compilateur ne pas vous arrêter d'appeler ce que vous voulez, et vous n'obtiendrez que des erreurs d'exécution, si vous appelez quelque chose qui n'existe pas. Aussi loin que la langue est concerné, vous pouvez appeler la méthode qu'une classe implémente sans erreurs à l'exécution, il n'existe aucun moyen permettant de limiter l'appel d'une méthode.

Personnellement, je pense que c'est effectivement une bonne chose. Nous obtenons donc utilisé pour l'encapsulation et la protection de notre code de code que nous avons parfois traiter l'appelant comme un sournois coupable plutôt que de la confiance d'un collègue ou d'un client. Je trouve que c'est assez agréable de code avec un état d'esprit de "vous faites votre travail et je fais le mien" où tout le monde respecte les limites et prend en charge leur propre chose. Vous pourriez dire que "l'attitude" de l'Objective-C est un de la confiance de la communauté, plutôt que de la stricte application de la loi. Par exemple, je suis heureux d'aider toute personne qui vient à mon bureau, mais il serait vraiment ennuyé si quelqu'un raté avec mon stuff ou déplacé les choses autour de vous sans vous le demander. Bien conçu, le code ne doit pas être paranoïaque ou sociopathe, il n'a qu'à bien travailler ensemble. :-)

Cela dit, il existe de nombreuses approches pour la structuration de vos interfaces, selon le niveau de granularité que vous voulez/besoin d'en exposer les interfaces pour les utilisateurs. Toutes les méthodes déclarées dans l'en-tête public sont essentiellement des règles du jeu équitables pour toute personne à utiliser. Cacher des déclarations de méthode est un peu comme le verrouillage de votre voiture ou de la maison - il ne sera probablement pas garder tout le monde, mais (1) il conserve les honnêtes gens honnêtes" de ne pas les tenter avec quelque chose qu'ils ne devraient pas être de jouer avec, et (2) toute personne qui fait entrer le sais certainement qu'ils n'étaient pas censés le faire, et ne peut pas vraiment se plaindre des conséquences négatives.

Ci-dessous sont quelques-uns des conventions-je utiliser pour les noms de fichier, et ce qui se passe dans chaque fichier à partir d'un .m fichier en bas, chaque fichier comprend l'un au-dessus d'elle. (À l'aide d'un strict de la chaîne de comprend permettra d'éviter des choses comme le double symbole d'avertissement.) Certains de ces niveaux s'appliquent uniquement aux plus grands composants réutilisables, tels que le Cacao cadres. De les adapter en fonction de vos besoins, et utilisez tous les noms qui vous convient.

• MyClass.h - Public de l'API (Interface de Programmation d'Application)
• MyClass_Private.h - L'intérieur de l'entreprise SPI (Système Interface de Programmation)
• MyClass_Internal.h - Projet interne de l'IPI (Interne Interface de Programmation)
• MyClass.m - Mise en œuvre, généralement de toutes les API/SPI/IPI déclarations
• MyClass_Foo.m - Mise en œuvre complémentaire, comme pour les catégories

L'API est pour tout le monde, et est soutenu publiquement (généralement en Foo.framework/Headers). SPI expose des fonctionnalités supplémentaires pour les clients internes de votre code, mais avec la compréhension que le soutien peut être limitée, et l'interface est sujet à changement (généralement en Foo.framework/PrivateHeaders). L'IPI se compose de la mise en œuvre des détails spécifiques qui ne doivent jamais être utilisés à l'extérieur du projet lui-même, et ces en-têtes ne sont pas inclus dans le cadre du tout. Toute personne qui choisit d'utiliser le SPI et l'IIP appels, le fait à ses propres risques, et souvent à leur détriment, lorsque des modifications de leurs casser le code. :-)

Answer 2

Déclarer les méthodes dans le fichier d'en-tête ne s'arrêtera que les avertissements du compilateur. Objective-C est un langage dynamique, de sorte que vous pouvez appeler une méthode (envoyer un message) à un objet de savoir si ou non de cette méthode est déclarée à l'extérieur.

Aussi, si vous définissez une méthode dans l' .m fichier ci-dessus le code qui l'appelle (paresseux déclaration) puis qui ne génèrent pas de toutes les mises en garde. Cependant, la même chose s'applique, vous pouvez envoyer un message à un objet sans qu'il soit déclaré.

Bien sûr, cela signifie qu'il n'existe pas de méthodes privées en Objective-C. la méthode qu'une classe implémente peut être appelé.

De préférence personnelle. Si c'est une méthode publique (j'.e utilisé à l'extérieur). il déclare dans les .h et de définir dans le .m. Si vous voulez limiter la visibilité, ou au moins indiquer que c'est une méthode privée, l'utilisation de catégories/les extensions de la classe dans la .m de fichier. Bien que beaucoup d'exemple de code utilise le plus paresseux de la déclaration de la méthode.

Answer 3

Objective-C traite des fonctions de "messages" et en tant que tel, vous pouvez envoyer un "message" à n'importe quel objet, même celui qui n'est pas explicitement état dans son interface qu'il peut accepter. En conséquence, il n'y a pas des choses telles que les députés d'en Obj-C.

Cela peut être très puissant, mais il est une source de confusion pour les nouveaux Obj-C programmeurs, notamment ceux qui viennent de C++, Java ou C#. Voici les règles de base de base:

• Vous devez définir toutes les méthodes publiques de votre @interface afin que les consommateurs sachent quels sont les messages que vous vous attendez à manipuler.
• Vous devez définir @méthodes privées dans votre @interface pour éviter les messages compilateur et d'éviter d'avoir à commander des méthodes dans votre @mise en œuvre.
• Vous devriez utiliser des protocoles lors de la mise en œuvre d'une convention particulière de méthodes pour votre classe.

Beaucoup de ceci est de préférence personnelle, mais il aide à éviter d'agacer les avertissements du compilateur et maintient votre code organisé. et facile à comprendre.