Discussion :

[ypelissier]

Bonjour,
Une petite question de convention de nommage que j'applique depuis longtemps mais qui me laisse pantois devant certains nommages de Microsoft lui-même...
J'ai des interfaces que je nomme habituellement IMyObect pour l'objet MyObject => Je l'applique depuis longtemps
Par contre en regardant un peu ce qu'il y a dans système.reflexion, certaines interfaces sont nommées _MyObject (par exemple _MemberInfo ou _PropertyInfo) Je trouve cela intéressant comme ça les interfaces ne sont pas au milieu des objets commençant par I... Qu'en pensez-vous ?

Merci

[DotNetMatt]

Je ne sais pas si c'est volontaire de la part de Microsoft. Ca peut etre du a une refactorisation de ton logiciel de decompilation…

En tout cas dans la doc officielle, Microsoft recommande l'usage de la letter "I" : Noms de classes, de structures et d'interfaces. Apres ca ne reste qu'une suggestion de convention, chacun est libre d'utiliser ce qu'il souhaite. Il faut juste savoir que pour integrer des developpeurs sur un projet, c'est plus simple en suivant les conventions les plus connues. Si tu utilises ta propre convention, il faut documenter et prevoir du temps pour que tes gars trouvent leurs marques.

Sinon pour isoler les interfaces du reste des objets, tu peux les conserver au sein d'un projet distinct. Par exemple :

• TonProjet.TonNamespace (qui contient les implementations)
• TonProjet.TonNamespace.Interfaces (qui ne contient que les interfaces)

Si tu utilises l'injection de dependences, ce genre de structure est plutot habituel, mais pas obligatoire.

[Kyroon]

Bonjour,

En regardant sur les sources de référence fournis par Microsoft, ils utilisent les deux préfixes I et _ pour les interfaces, par exemple pour MemberInfo (https://referencesource.microsoft.co...37137ea25e482a)

Je n'ai aucune idée du pourquoi, peut-être un reste avant qu'il utilise la convention du I.

Personnellement, je reste sur le I, comme le dit DotNetMatt, ça reste la plus connue et la plus simple à intégrer.

Bonne continuation.

[ypelissier]

OK, je vous remercie

[François DORIN]

Très pertinente cette remarque.

En regardant un peu le code, j'ai peut être des éléments de réponse à donner. Je pense que c'est une convention de nommage volontaire et réfléchie.

On peut constater, pour l'interface _MemberInfo, que les membres définis dépendent de la directive préprocesseur FEATURE_CORECLR.
Ensuite, il est marqué que ces interfaces ne sont pas CLS Compliant (en gros, cela signifie que le code n'est pas langage agnostique et donc qu'il dépend du C#. Il ne sera pas forcément possible de l'utiliser depuis un autre langage comme VB.NET).
De plus, l'interface est implémentée de manière explicite. Autrement dit, à moins d'avoir une variable de type _MemberInfo, il ne sera pas possible d'appeler les méthodes défini par cette interface.
Enfin, l'interface est visiblement présente pour une interopérabilité COM.

Comme cette interface n'a pas vocation a être utilisée dans du code managé, mais qu'elle est nécessaire publique puisque c'est un composant COM, Microsoft "masque" l'interface en usant une convention différente de celle recommandée.

[Noxen]

Personnellement je suis tombé sur ce formalisme en travaillant sur des plugins MS Office. Dans interop (Microsoft.Office.Interop.<Word/Excel/Outlook/...> pour accéder aux objets COM on trouve des interfaces _Application (exemple) qui doivent utilisées explicitement dans des cas précis ; notamment pour pallier des ambigüités de nommage entre des événements, méthodes ou propriétés.