Comment éviter les similitudes de noms entre vos classes et celles natives? [fermé]

9

Je viens de rencontrer un "problème intéressant", sur lequel j'aimerais avoir votre avis:

Je développe un système et pour de nombreuses raisons (c'est-à-dire: abstraction, indépendance technologique, etc.) nous créons nos propres types d'échange d'informations.

Par exemple: s'il existe une méthode appelée SendEmail et invoquée par la logique métier, elle possède un paramètre de type OurCompany.EMailMessage, qui est un objet totalement indépendant de la technologie et ne contenant que des "données pertinentes pour l'entreprise" (pour exemple, aucune information sur le codage de la tête).

Dans la fonction SendEmail, nous obtenons ces informations de notre objet EMailMEssage et créons un objet MailMessage (celui-ci est spécifique à la technologie) afin qu'il puisse être envoyé sur le réseau.

Comme vous pouvez déjà le remarquer, notre classe a un nom très similaire à la classe de langue "native". Le problème est: c'est exactement ce qu'ils sont, des e-mails, il est donc difficile de leur trouver un autre nom significatif.

Avez-vous souvent ce problème? Comment gères-tu ça?

Edit: @mgkrebbs vient de commenter l'utilisation de noms pleinement qualifiés. C'est notre approche actuelle, mais un peu trop verbeuse, à mon humble avis. J'aimerais quelque chose de plus propre, si possible.

naming coding-standards variables

— JSBach
source

2

Toujours utiliser la qualification semble une solution viable, même si elle est un peu verbeuse. Utilisez OurCompany.EMailMessage pour un type et SendEmailClass.EMailMessage (ou autre) pour l'autre. Y a-t-il un problème avec cette approche?

— mgkrebbs

Oui, j'y ai pensé, mais ça devient verbeux. Je voudrais quelque chose de "plus propre", mais la solution que vous proposez est ma solution actuelle. J'ajouterai ceci à l'explication

— JSBach

3

Les noms viennent dans un contexte. Habituellement, un espace de noms ou quelque chose comme ça. Cela ne devrait donc pas poser de problème.

— deadalnix

+1, j'aime cette question. J'ai posé cette question à un instructeur il y a environ 7 ans, et il pensait que je suis un "...." complet :)

— NoChance

Quelle langue utilisez-vous? La réponse est spécifique à la langue. En général, la réponse est «utiliser un espace de noms». Dans une seule application Java, il est assez courant que le même nom de classe soit utilisé par une demi-douzaine de bibliothèques.

— Kevin Cline

3

Il s'agit d'un problème concernant l'espace de noms que vous allez utiliser pour votre projet.

Fondamentalement, un espace de noms est la collection des mots clés fournis par toutes vos classes et / ou toutes les classes que vous souhaitez utiliser dans votre projet (y compris les classes standard généralement fournies avec le langage / compilateur / IDE).

Étant donné qu'un espace de noms est une collection, certaines règles fondamentales sont appliquées pour empêcher la création d'un gâchis de termes sans aucun comportement associé, et certains langages comme le C # vous permettent également de définir votre propre espace de noms comme d'habitude et de l'utiliser dans d'autres classes.

Ne confondez pas l'espace de noms avec le mot-clé de base de la langue, ils sont à la fois une collection de mots-clés mais avec une grande différence entre les deux: vous pouvez modifier un espace de noms mais vous ne pouvez généralement pas modifier les mots-clés de base d'une langue. La somme entre l'espace de noms que vous avez utilisé dans votre projet et les mots clés de base de la langue que vous utilisez vous donne le nombre total de mots clés.

Le sujet est largement discuté sur le net, je peux suggérer une recherche de base avec les termes "namespace [votre langue]" ou quelque chose comme ça. Je ne réponds pas directement à votre question simplement parce que vous pouvez avoir une approche différente pour différentes langues.

— Micro
source

3

Eh bien, mon ancienne équipe de développement utilisait pour ajouter l'acronyme de l'application dans chaque classe personnalisée. Nous avions par exemple la classe ABCEmail .

Je pense que c'est plus simple que de s'appuyer sur l'espace de noms, mais peut également être une solution complémentaire à l'utilisation de l'espace de noms.

Dernier point mais non le moindre, puisque vous créez un nouvel objet, cela signifie que l'objet natif ne répond pas à vos besoins, donc votre nom de votre fichier e-mail pourrait être CustomizedEmail , AdvancedEmail ... etc

— Amine
source

1

D'accord avec votre dernier point, mais pourquoi serait OAEmailmieux que OurApplication.Email? OAEMaila un impact sur chaque partie du logiciel, tandis que la notation d'espace de noms n'a un impact que là où la conversion se produit et les deux classes sont utilisées dans le même fichier source.

— Steven Jeuris

1

Je pense que le préfixe est une bonne idée lorsque votre langue ne prend pas en charge les espaces de noms. Mais si le langage prend en charge une forme sur l'espace de noms, utilisez-le (c'est le problème que les espaces de noms ont été conçus pour résoudre!). '

— Martin York

@Steven Jeuris: Le nom de la classe doit être sélectionné une fois créé. Après, je trouve que c'est une mauvaise pratique de le changer ... à cause de tous les impacts inutiles.

— Amine

@Loki Astari: je ne sais pas quel IDE vous utilisez mais je trouve qu'un nom de classe différent est plus facile à gérer lors de la recherche ou de l'ouverture d'une classe donnée. J'ai vu des projets ayant une version personnalisée de "e-mail" et chaque fois que je voulais ouvrir le fichier, je devais parcourir plusieurs espaces de noms. Votre argument est toujours valable, je suppose que le nombre de classes personnalisées qui seront créées dépend de l'organisation du package.

— Amine

1

@Amine: Je ne savais pas que vous argumentiez contre les espaces de noms. Je vous suggère de lire un peu plus sur les espaces de noms pour voir tous les avantages de les utiliser: encapsulation, éliminer l'ambiguïté, moins de redondance, ... Ps: La plupart des IDE modernes ont des fonctionnalités de recherche qui vous permettent de trouver rapidement un fichier source sans avoir à parcourir la hiérarchie. Quant à votre commentaire: le refactoring constant fait partie du développement logiciel. Lorsque vous pouvez trouver un nom plus approprié, à fort impact ou non, vous devriez envisager de le renommer. Il est cependant préférable d'en discuter d'abord avec des collègues.

— Steven Jeuris

3

Quelle langue utilisez-vous? La réponse est spécifique à la langue. En général, la réponse est «utiliser des espaces de noms». Je ne modifierais presque jamais le nom du type pour éviter un conflit avec un espace de noms externe.

Dans une seule application Java, il est assez courant d'avoir le même nom de classe (par exemple "Date") défini dans une demi-douzaine d'espaces de noms. Si une classe doit utiliser deux classes Date distinctes, alors l'une des classes Date doit être pleinement qualifiée partout où elle apparaît, car Java ne prend pas en charge les alias de type. En C ++, la vie est plus facile; vous pouvez simplement renommer l'un d'eux avec un typedef.

— kevin cline
source

J'étais sur le point de poster une réponse similaire, mais au lieu de l'exemple d'alias C ++, je voulais mentionner les C # utilisant la directive alias .

— Steven Jeuris

@Steven: J'allais mentionner C # au lieu de C ++, mais cela fait quelques années que je n'ai pas programmé en C #, et je n'en étais pas sûr.

— Kevin Cline du

2

Avez-vous souvent ce problème? Comment gères-tu ça?

Cela dépend vraiment de la langue que vous utilisez. En c ++ et java, ce problème est résolu en utilisant des espaces de noms. J'utilise c ++, et il m'arrive d'avoir différentes classes avec le même nom. Ce n'est pas un problème, car ils sont dans des espaces de noms différents.

Dans d'autres langues, il n'y a pas d'autre moyen que de fournir des noms différents.

— BЈовић
source

Pour l'ordinateur, ce n'est pas un problème, mais pour le développeur, c'est possible, car vous avez par exemple EmailMessage et MailMessage.

— JSBach

@Oscar Évidemment. Pour l'ordinateur, cela peut être xyz123et cela fonctionne toujours de la même manière. Je ne vois pas d'autre moyen que de devenir verbeux (vous avez dit dans les commentaires que vous essayez de l'éviter).

— BЈовић

2

Votre question est très bonne. Et si vous préfixez votre méthode avec un préfixe tel que U (ou u) ou cls (abréviation de class)? Pour des exemples:

clsEMailMEssage ou uEMailMEssage

Cela ne nécessite pas beaucoup de saisie et vous pouvez immédiatement dire que le type est le vôtre.

Edit - En réponse aux 2 premiers commentaires:

Je voudrais attirer l'attention du lecteur sur le fait que: Toutes les notations hongroises ne sont pas créées égales. Nous devons faire la distinction entre le système hongrois et les applications hongroises , je suppose que la suggestion ci-dessus suit le type d'applications hongroises, ce qui n'est pas dangereux.

Le préjudice associé à la notation hongroise du système, comme le fait de nommer un ID, un intID n'est pas présent dans la suggestion ci-dessus.

Pour en savoir plus à ce sujet, jetez un œil à: Rendre le code incorrect faux - Joel On Software

— Aucune chance
source

3

Chaque fois que quelqu'un recommande la notation hongroise, Dieu tue un chaton.

— Konamiman

2

Le BIgHUmpCAmelCAsing n'aide pas non plus.

— Steven Jeuris

Les commentaires ci-dessus sont appréciés. Veuillez voir mes modifications, même si je sais que certains d'entre nous ne changeront pas d'avis, après tout, qui veut qu'un chaton soit tué? :)

— NoChance

J'ai supprimé le vote négatif maintenant que vous avez ajouté un raisonnement valable. Cependant, je ne suis pas d'accord que les applications hongroises sont plus appropriées que les espaces de noms dans ce scénario. Lorsque le langage prend en charge les alias, c'est une solution beaucoup plus appropriée. Voir la réponse de Kevin Cline .

— Steven Jeuris

@Steven Jeuris, merci pour votre commentaire. Les espaces de noms sont parfaits sauf qu'ils sont un peu longs à continuer à taper, je vais vérifier le lien que vous avez fourni.

— NoChance