7
votes

Convention de nommage de classe Objective-C vs oncle Bob

in Chapitre 2: noms significatifs oncle Bob écrit:

n'aime pas le contexte gratuit

Dans une application imaginaire appelée "Station d'essence Deluxe", c'est une mauvaise idée de préfixer chaque classe avec GDS . Franchement, vous travaillez contre vos outils. Vous tapez g et la touche d'achèvement de la presse et sont récompensés par une liste de chaque classe de chaque classe de votre système

En fait, ce que j'ai découvert pendant mes premiers jours avec Objective-C un peu plus d'un an. Après Java, c'était tout à fait décevant mais je pensais que je suis seulement celui qui ennuyait à ce sujet :) Je comprends que le livre "Clean Code" fait référence à Java la plupart du temps et Java a des espaces de noms (packages) contrairement à l'objectif-c.

Utilisez-vous 2-3 lettres préfixes dans vos cours si vous construisez une application, pas une bibliothèque? Selon vous, est-ce que c'est une mauvaise conception de la langue, une "caractéristique" ou une oncle Bob n'allait pas ici?


6 Réponses :


0
votes

Personnellement, je n'utilise presque jamais de préfixes. Les seules exceptions sont les classes qui sont en quelque sorte connectées les unes aux autres ou elles doivent toutes être présentes.

Un exemple:

Une application client pour le chat. Appelons ce chat un examplechat .

alors j'utiliserais ecmessage , écuseur , ecroom , etc. Pour voir facilement quelles classes devraient y avoir.

ou si je fais des cellules personnalisées pour UitailView J'utiliserais des préfixes pour les garder tous les uns proches les uns des autres et ne pas avoir de lutter pour les chercher dans une "liste des milles". Exemple:

ectextMessagecell , ECSoundMessagecell , ECUploadMessagecell , Ecjoinorleavemessagecell , etc.

C'est mon opinion personnelle, qui ne peut pas être la meilleure. Mais c'est toujours le plus facile pour moi.

espère qu'il aide


5 commentaires

Je mettais toutes ces classes dans un EXAMPLCHAT Espace de noms ou espace de sous-noms où la langue permet. Les préfixes ne sont utiles que lorsque les espaces de noms ne sont pas une option (ce que nous discutons.)


Je suis avec vous en cas de langues comme Objective-C où aucun packages / espaces de noms ou un concept similaire disponible pour la structuration de la source.


C'est une situation exacte décrite dans le code de nettoyage et elle est mentionnée comme une mauvaise pratique. Je suis tout à fait d'accord avec Oncle Bob, mais je pense que c'est une faute de la syntaxe de langues (aucun espaces de noms pour les classes)


C'est une faute de la langue, mais l'oncle Bob a tort de dire aux lecteurs de ne pas utiliser la solution de contournement standard (préfixes.)


Je ne dirais pas qu'il a tort. Il ne dit pas de ne pas les utiliser. Il a dit que c'est une mauvaise convention de dénomination. Et ici, je conviendrais avec lui. Mais dans l'objectif-C, nous l'avons comme une convention de dénomination standard que nous sommes forcés d'utiliser.



0
votes

Eh bien, si vous n'avez pas d'espaces de noms, les conflits de noms sont susceptibles de se produire. Vous pouvez voir cela dans beaucoup de bibliothèques C qu'ils utilisent une sorte de préfixe. Je suppose donc qu'il y a de bonnes raisons d'avoir ces préfixes et d'autres raisons de ne pas l'utiliser. Mais quel devrait être le gros problème pour modifier l'achèvement d'être soit ignoré simplement le préfixe de taper trois lettres au lieu d'une seule.

Donc, à la fin, il me semble une question de goût. Je suppose qu'il serait plus important d'avoir de bonnes catégories de structures avec des préfixes au lieu d'un gâchis de classes sans préfixe ....

Cela n'a rien à voir avec la mauvaise conception de la langue imho. Il y avait un temps où le logiciel n'était pas partout et pourquoi faut-il perdre des efforts supplémentaires sur les espaces de noms? Et toujours comme nous pouvons voir même aujourd'hui les langues sans espaces de noms sont utilisés .....


3 commentaires

Objective-C 3.0 a environ 1 an ou plus. Ils avaient une chance de résoudre le problème avec les espaces de noms, alors argument sur les temps âgés ne fonctionne pas ici imho


Pas familier avec "Objective-C 3.0". Pouvez-vous vous fournir un lien?


Je suis désolé, c'était typo, 2.0. Et j'ai commis une erreur qu'un âge. C'est il y a environ 5 ans. Quoi qu'il en soit, ce n'est pas trop vieux, non? :)



0
votes

Je dirais que le monde n'est pas noir ou blanc. Je programmant en Java, avec des packages et oui, il est gênant d'avoir un préfixe dans chaque classe, ainsi que d'être ennuyeux et arguouble pour commencer les interfaces avec I (tout comme celle-ci utilisée pour le faire).

Parfois, cela me gêne dans Objective-C, mais il a une légitimité si vous n'avez pas de paquets dans votre langue, car vous pouvez «construire» des groupes artificiels de classes comme «NS», «UI», 'MK' et Donc, dans l'Objc et le cacao.


2 commentaires

Mais c'est une faute de la langue. De plus, il y a des chances que j'aurai nommer une collision avec Exmessage, alors dans COM.Example.Message est un million de fois plus élevé.


Je ne sais pas si nous pouvons simplement la qualifier de faute, mais plutôt une fonctionnalité ou une restriction. Le manque d'objets et espaces de noms est-il une faute de langue dans C? Je préférerais dire que cela fait partie de la caractéristique de la langue. Et si nous considérons que la langue est une sorte d'instruments que chacun d'eux a sa propre façon d'utiliser. Certaines pratiques sont valables ou même préférables en une mais absolument non-bille dans une autre.



3
votes

J'ai été tenté de fermer cette question, mais je ne pense pas avoir vu un similaire posé auparavant et c'est une question valable. Voici mes pensées plutôt désorganisées sur la question.

De nombreuses langues ont une fonctionnalité appelée espaces de noms , où le nom de classe "entièrement qualifié" est préfixé par une série hiérarchique de noms. Par exemple, la classe string en Java est, correctement, java.lang.string et une classe personnalisée est correctement com.whatever.foobar.myclass .

Malheureusement, les espaces de noms n'ont jamais été ajoutés à l'objectif-C, ce qui signifie que les symboles de l'objectif-C (noms de classe, noms de protocoles et quelques autres types) ne peuvent pas être placés dans un espace de noms même lors de l'utilisation de l'objectif-C ++ (qui a une fonction d'espace de noms pour les fonctions, les constantes, les structures, etc.)

La seule solution pour empêcher les collisions de symboles dans le code partagé, il est donc d'utiliser une forme de nom de nom de nom pour rendre vos noms de symboles uniques. Dans l'objectif-C, la Convention est d'utiliser un préfixe de deux caractères (parfois le nombre varie) pour toutes vos classes.

Cet oncle Bob Associer est un twit pour vous dire de ne pas faire cela, car pendant que vous vous retrouvez avec un programme qui ne compile pas, vous perdrez aucun avantage des espaces de noms qui préfixent encore. Votre application utilise-t-elle des plug-ins? Vous devez préfixer. Votre application a-t-elle une API publique? Vous devez préfixer.

En théorie, code dans une seule application qui ne touche jamais le monde extérieur peut se passer de préfixes, mais vissez-le - continuez de coder proprement et ajoutez un préfixe même là. Ça vous sauvera chagrin plus tard.


0 commentaires

12
votes

Peut-être que le mot clé ici est gratuit . Dans l'objectif-C, les préfixes servent l'objectif important de réduire les risques de collisions de noms. Dans d'autres langues telles que Java et C ++, l'existence de la prise en charge des espaces de noms rend l'utilisation des préfixes gratuite (et une violation du principe sec de l'OFT-cité). Dans l'objectif-C, cependant, les préfixes sont significatifs, utiles et pas gratuits.


2 commentaires

Merci. Je comprends pourquoi les préfixes de classe sont inclus dans les conventions de codage de la langue. Cependant, je pense que les espaces de noms sont beaucoup mieux une solution et c'est un peu étrange que la langue assez moderne ne les a pas.


@Orogneswamp Deux choses à retenir sur l'objectif-C sont que c'est aussi vieux que c ++ (tous deux apparu en 1983) et que, dans de nombreux cas, cela évite les caractéristiques et la complexité et les remplace avec la convention et le style. Peut-être que les espaces de noms sont si utiles et constitueraient une telle amélioration de la langue qu'il vaut la peine de les introduire en tant que caractéristique linguistique. (Je ne le pense pas.) De toute façon, mon objectif n'était pas d'expliquer les préfixes, mais à souligner que la ligne directrice ne signifie pas que les préfixes sont mauvaises, seuls les préfixes sont mauvais si elles ne servent pas de but.



0
votes

Au-delà d'éviter les collisions, l'un des avantages que les préfixes de noms indiquent que vous êtes immédiatement au courant de ce que vous avez vraiment affaire. Supposons que vous ayez le code suivant: xxx

d'un coup d'œil curseur au code et en fonction des bibliothèques que vous avez utilisées, ces types pourraient provenir d'un certain nombre de sources différentes. Vous devrez peut-être avoir à rechercher l'instruction Inclure / importation de comprendre ce que le type peut faire (par exemple, vous souhaitez la modifier, mais il manque une méthode que vous êtes certainement là).

dans l'iOS Monde, vous sauriez immédiatement s'il s'agit d'un UICOLOR contre un CGCOLOR et d'obtenir un contexte immédiat.

Dans le passé à la WWDC, Apple organiserait une session où ils ont expliqué des conventions de codage Cacao / Objective-C. Je crois qu'ils mentionnent cet aspect des préfixes de noms afin que vous souhaitiez trouver l'un des enregistrements mis à disposition. D'autres développeurs C (E.G. Développeurs de noyau Linux) ne semblent également pas penser à des espaces de noms C ++ (parmi d'autres fonctionnalités C ++) pour diverses raisons.


1 commentaires

Merci Bryant. Mais je pense que Uicolor et CGColor dans le cadre standard constituent un autre exemple de la conception "mauvaise".