Convention de nommage d'interface
C'est une chose subjective bien sûr, mais je ne vois rien de positif dans la préfixe des noms d'interface avec un 'Je'. Pour moi, Thing est pratiquement toujours plus lisible que IThing.
Ma question est la suivante: pourquoi cette convention existe-t-elle alors? Bien sûr, il est plus facile de distinguer les interfaces des autres types. Mais cet argument ne va-t-il pas s'étendre au maintien de la notation hongroise, qui est maintenant largement censurée?
Quel est votre argument pour ce "moi" maladroit? Ou, plus important encore, que pourrait-il appartenir à Microsoft?
Les conventions (et les critiques à leur encontre) ont toutes une raison d'être, alors trouvons quelques raisons derrière les conventions
Les interfaces ont le préfixe I pour différencier les types d'interface des implémentations - p.ex., comme mentionné ci-dessus, il doit exister un moyen facile de faire la distinction entre
Thinget son interfaceIThingafin que la convention serve cet objectif.Les interfaces ont le préfixe I pour le différencier des classes abstraites - Il y a une ambiguïté lorsque vous voyez le code suivant:
public class Apple: FruitSans la convention, on ne saurait pas si
Appleétait héritant d'une autre classe nomméeFruitou s'il s'agissait d'un implémentation d'une interface nomméeFruit, alors queIFruitrendra ceci évident:public class Apple: IFruitLe principe de la moindre surprise s'applique.
Toutes les utilisations de la notation hongroise ne sont pas censurées - Les premières utilisations de la notation hongroise signifiaient un préfixe indiquant le type de l'objet, suivi du nom de la variable ou parfois d'un soulignement avant le nom de la variable. Cela était utile pour certains environnements de programmation (pensez à Visual Basic 4 - 6), mais à mesure que la popularité de la programmation orientée objet grandissait, il devenait impraticable et redondant de spécifier le type. Cela est devenu particulièrement problématique en ce qui concerne intellisense.
Aujourd'hui, la notation hongroise est acceptable pour distinguer les éléments d'interface utilisateur des données réelles et des éléments d'interface utilisateur similaires associés, par exemple,
txtObjectpour une zone de texte,lblObjectpour l'étiquette associée à cette zone de texte, tandis que les données pour la zone de texte sont simplementObject.Je dois également souligner que l'utilisation originale de la notation hongroise ne visait pas à spécifier des types de données (appelée notation hongroise système) mais plutôt à spécifier l'utilisation sémantique d'un nom de variable (appelée notation hongroise Apps). Plus d'informations à ce sujet sur l'entrée de wikipedia sur la notation hongroise .
Eh bien, une considération évidente serait la paire (très commune) IFoo et Foo (lors de l’abstraction de Foo), mais plus généralement, il est souvent fondamental de savoir si quelque chose est une interface vs classe. Oui, il est partiellement redondant, mais IMO est différent des choses telles que sCustomerName - ici, le nom lui-même (customerName) devrait suffire à comprendre la variable.
Mais avec CustomerRepository - est-ce qu’une classe ou l’interface abstraite?
Aussi: attente; le fait est, vrai ou faux, c'est ce à quoi les gens s'attendent. C'est presque raison suffisante.
La raison pour laquelle je le fais est simple: parce que c'est la convention. Je préférerais simplement le suivre plutôt que de faire en sorte que mon code soit différent, ce qui le rend plus difficile à lire et à apprendre.
Thing est un nom plus lisible que IThing. Je viens de l'école de pensée selon laquelle nous devrions programmer des interfaces plutôt que des implémentations spécifiques. En règle générale, les interfaces doivent donc avoir la priorité sur les implémentations. Je préfère donner le nom plus lisible à l'interface plutôt qu'à l'implémentation (c'est-à-dire que mes interfaces sont nommées sans le préfixe «I»).
À mon avis, ce «je» n'est qu'un bruit visuel. IDE devrait afficher les noms de classe et d'interface différemment. Heureusement, la bibliothèque standard Java n'utilise pas cette convention.
Je pense que c'est mieux que d'ajouter un suffixe "Impl" sur votre classe concrète. C'est une lettre unique, et cette convention est bien établie. Bien sûr, vous êtes libre d'utiliser le nom que vous souhaitez.
Je suis sûr que votre question a fait l’objet de nombreuses discussions au sein de l’équipe Microsoft qui a travaillé sur le .NET Framework et ses normes.
Je pense que l'exemple le plus parlant vient de la source elle-même. Ci-dessous, je transcris des extraits de Framework Design Guidelines , un livre que je recommande vivement.
De Krzysztof Cwalina, responsable du programme CLR:
Le seul préfixe utilisé est "I" pour les interfaces (comme dans
ICollection), mais cela pour des raisons historiques. Rétrospectivement, je pense qu’il aurait été préférable d’utiliser des noms de type normaux. Dans la majorité des cas, les développeurs ne s'inquiètent pas du fait que quelque chose est une interface et non une classe abstraite, par exemple.
Brad Abrams, responsable du programme CLR et .NET Framework:
D'autre part, le préfixe "I" sur les interfaces est une reconnaissance claire de l'influence de COM (et Java) sur le .NET Framework. COM popularisé, voire institutionnalisé, la notation des interfaces commence par "I." Bien que nous ayons discuté de la divergence par rapport à ce modèle historique, nous avons décidé de le conserver car bon nombre de nos utilisateurs connaissaient déjà COM.
De Jeffrey Richter, consultant et auteur:
Personnellement, j'aime bien le préfixe "I" et j'aimerais que nous ayons plus de choses comme ça. Les petits préfixes à un caractère permettent de garder le code concis et descriptif. [...] J'utilise des préfixes pour mes champs de type privé car je trouve cela très utile.
Mon point est, il était sur la table de discussion. Je vois un avantage: cela évite les conflits de noms entre les classes et les interfaces, de sorte que vos noms peuvent être à la fois descriptifs et compacts.
Personnellement - et peut-être par habitude - j'aime bien le préfixe I, car il marque succinctement les interfaces, ce qui me permet d'avoir une correspondance de nommage un à un avec les types d'implémentation. Cela se manifeste lorsque vous souhaitez fournir une implémentation base: IThing est l'interface, Thing est le type de base (peut-être abstract). Les types dérivés peuvent être SomeThing. J'adore pouvoir utiliser cette notation abrégée d'une clarté cristalline.
Il n’ya rien de mal à ne pas utiliser la convention I avec I pour les interfaces - soyez juste cohérent et assurez-vous que cela fonctionne non seulement pour vous, mais pour toute l’équipe (le cas échéant).
Parce que vous avez généralement un truc et une chose. Ainsi, au lieu de laisser les gens venir avec leurs propres «conventions» pour cette situation récurrente, une convention uniforme unique a été choisie. En écho à ce que disent les autres, la normalité de facto est une raison suffisante pour l'utiliser.
Ne préfixe les noms d'interface avec le lettre I pour indiquer que le type est une interface.
La directive n’explique pas pourquoi vous devriez utiliser le préfixe I, mais le fait qu’il s’agisse maintenant d’une convention établie devrait suffire.
Qu'avez-vous à gagner en supprimant le préfixe I?
C'est juste une convention dont le but est d'empêcher les collisions de noms. C # ne me permet pas d'avoir une classe et une interface nommée Client, même si les noms de fichier sont Client et IClient, respectivement. Je suis à l'aise avec la convention. si je devais proposer une convention différente, je suggérerais d'utiliser "Contract" comme suffixe, par exemple. ClientContract.
Je ne sais pas exactement pourquoi ils ont choisi cette convention, pensant peut-être en partie à lier la classe avec "Je" comme dans "Je suis Enumerable".
Une convention de dénomination qui serait plus dans la ligne du reste du cadre serait d’incorporer le type dans le nom, comme par exemple les classes xxxAttribute et xxxException, ce qui en fait xxxInterface. C'est un peu long cependant, et après toutes les interfaces est quelque chose de séparé, pas juste un autre groupe de classes.
Pour séparer les interfaces des classes.
De plus (ceci est plus une observation personnelle que dictée d'en haut), les interfaces décrivent ce que fait une classe. Le «je» se prête à cela (je suis sûr que c'est une construction en grammaire qu'il serait bien de dévoiler maintenant) une interface qui décrit les classes qui valident serait "IValidate". "IMatch" est un exemple de comportement de correspondance.
Nommer une interface devrait avoir une signification beaucoup plus profonde que celle de savoir si vous mettez ou non un "I" devant le nom.
Ni "Fruit" ni "IFruit" n'auraient beaucoup de signification pour moi en tant qu'interface. C'est parce que cela ressemble beaucoup plus à une classe. Les classes définissent les choses, alors que les interfaces doivent définir les fonctionnalités.
La convention de nommage "I" permet de différencier les classes et les interfaces, facilitant ainsi le développement. Et bien que cela ne soit pas nécessaire, cela permet certainement d'éviter les maux de tête de codage orientés objet. C #, comme Java, n'autorise l'héritage que d'une seule classe de base. Mais vous pouvez implémenter autant d'interfaces que vous le souhaitez. L'avertissement est que, si vous héritez d'une classe et implémentez une ou plusieurs interfaces, la classe de base doit être nommée en premier (c'est-à-dire la classe Trout: Fish, ISwimmer, IDiver ...).
J'aime vraiment nommer mes interfaces en fonction de leurs fonctionnalités et de leur type d'interface (interfaces animées ou inanimées).
Si vous vous concentrez sur les fonctionnalités fournies par l'interface, vous pouvez rapidement déterminer le nom de l'interface. Il vous aide également à voir rapidement si votre interface définit des fonctions non liées.
Interfaces qui définissent des objets inanimés (c'est-à-dire des choses qui ne peuvent pas agir seules) ......... J'aime les nommer avec ... capable à la fin IPrintable (tel que Document, Facture) IPlayable (tel que Instrument, MediaPlayer) ISavable (tel que Document, Image) IEdible (tel que Fruit, Beef) IDrivable (tel que Car) IFlyable (tel que Plane)
Interfaces qui définissent des objets animés (c.-à-d. Des choses qui agissent par elles-mêmes) ......... J'aime les nommer par ... er à la fin ISwimer (comme Fish, Dog, Duck) IDiver (comme le poisson, le canard) IFlyer (comme le pilote) IDriver (comme le NascarDriver)
En fin de compte, la convention de nommage "I" permet de différencier les interfaces et les classes. Mais il peut être judicieux d’ajouter une logique de nommage supplémentaire au-delà du "I" au début.
Il semble hongrois ish pour moi. Le hongrois est généralement considéré comme une menace dans les langues fortement typées.
C # étant un produit Microsoft et la notation hongroise étant une invention de Microsoft, je peux voir où C # pourrait être susceptible de son influence.
Je connais les directives de Microsoft recommandant d'utiliser le «je» pour le décrire comme une interface. Mais cela vient des conventions de dénomination IBM si je ne me souviens pas bien, du "I" initiateur pour les interfaces et du * Impl suivant pour les implémentations.
Cependant, à mon avis, les conventions de dénomination Java constituent un meilleur choix que la convention de dénomination IBM (et pas seulement en Java, pour C # également et pour tout langage de programmation OO). Les interfaces décrivent ce qu'un objet peut être capable de faire s'il implémente l'interface et si la description doit être sous forme verbale. Ie Runnable, Serializable, Invoiceable, etc. IMHO c'est une description parfaite de ce que représente l'interface.
Il est courant pour une interface utilisateur graphique d’utiliser différentes icônes pour les fichiers et les dossiers. S'ils partagent tous les mêmes icônes, mais que les dossiers portent le préfixe "F", il serait acceptable d'utiliser la même icône. Mais comme la vitesse de reconnaissance des images par les humains est plus rapide que leur vitesse de reconnaissance des mots, nous avons opté pour des icônes.
Les programmes informatiques tels que les IDE sont parfaitement capables de rendre apparente l’interface d’un fichier. Cela libérerait l'espace de noms de différents niveaux d'abstraction se produisant sous le même nom. Par exemple. Dans "ICare", "I" décrit la mise en oeuvre et "Care" décrit les capacités de l'interface.
Je suppose que la convention "I" est si populaire parce que nous n’avons pu penser à rien de mieux, mais son existence est importante car elle souligne la nécessité de connaître ce type d’informations.
Le fait est que tout le monde le comprend et que pour écrire un meilleur code, il est facile à lire et à comprendre.
Vous pouvez ajouter le mot "Interface" comme suffixe à votre interface personnalisée, par exemple "SerializerInterface". Pour la classe abstraite, "Fruit", par exemple, "FruitAbstract" ou vous pouvez le transformer en "AbstractFruit", soyez cohérent tout au long. Cela est suffisamment lisible ou suit la convention de nommage habituelle.
Juste mes 2 centimes:
La raison pour laquelle j’ajoute personnellement le suffixe "Interface" est qu’il est plus facile à lire que le préfixe "I" et que les fichiers du système sont répertoriés "groupés". Par exemple:
Pas si bon:
Alien.php
Host.php
IAlien.php
IHost.php
IXenomorph.php
Xenomorph.php
Meilleur:
Alien.php
AlienInterface.php
Host.php
HostInterface.php
Xenomorph.php
XenomorphInterface.php
Mais c'est juste un goût personnel. Je pense que tant que l'on utilise une convention de dénomination cohérente tout au long du projet, rien ne s'oppose à l'utilisation de votre propre convention de dénomination.
Je n'aime pas vraiment cette convention. Je comprends que cela aide dans le cas où vous avez une interface et une implémentation qui porterait le même nom, mais je trouve ça moche. Je suivrais quand même si c'était la convention où je travaille, bien sûr. La cohérence est le but des conventions et la cohérence est une très bonne chose.
J'aime avoir une interface décrivant ce qu'elle fait de manière aussi générique que possible, par exemple, Validator. Une implémentation spécifique qui valide une chose particulière serait une ThingValidator, et une implémentation avec certaines fonctionnalités abstraites partagées par Validators serait une AbstractValidator. Je le ferais même si Thing est la seule ... eh bien ... chose que je valide, et Validator serait générique.
Dans les cas où une seule classe concrète a du sens pour une interface, j'essaie toujours de décrire quelque chose de spécifique à propos de cette implémentation plutôt que de nommer l'interface différemment pour éviter une collision de noms. Après tout, je vais taper le nom de l'interface plus souvent que le nom de l'implémentation.