L'utilisation du même nom pour l'espace de noms et la classe à l'intérieur est problématique.
Si l'espace de noms contient plusieurs classes, pourquoi y aurait-il d'autres classes? cela ne semble pas correct, car le but du nom de l'espace de noms est de décrire toutes les classes qu'il contient , pas seulement une. Par exemple, si vous avez JsonSerialization
, BinarySerialization
et des XmlSerialization
classes dans un espace de noms, serait - il judicieux de nommer votre espace XmlSerialization
?
Ce qui se produit généralement, c'est qu'en raison d'une extraction d'une classe à partir d'un espace de noms existant, ou d'une fusion entre plusieurs classes ou d'une autre réorganisation, vous vous retrouvez avec un espace de noms contenant une classe principale ; progressivement, des classes mineures y sont mises car elles sont légèrement liées à la classe d'origine. Par exemple, un espace de noms LogParser
peut contenir une seule classe LogParser
, puis quelqu'un le place LogConverter
, car il est assez lié à l'analyseur, alors LogSearcher
, etc. Le problème ici est que le nom de l'espace de noms n'a pas été changé: dès qu'il a LogConverter
été ajouté, le le nom aurait dû être changé LogsProcessing
ou, tout simplement, Logs
.
Si l'espace de noms ne contient qu'une seule classe, cela peut être le signe d'un problème au sein de l'organisation du code.
Bien que j'ai vu à quelques reprises les situations où une seule classe avec des principes SOLID appropriés était très différente de toute autre chose dans la base de code et était donc placée dans un espace de noms dédié, de tels cas sont rares. Le plus souvent, cela indique un problème. De même, rien ne vous empêche d'avoir une classe contenant une seule méthode, mais le plus souvent, ces classes indiquent un problème.
Même si votre espace de noms ne contient qu'une seule classe, il existe généralement un moyen d'être plus précis lors du nommage de la classe et plus général lors du nommage de l'espace de noms. Imaginez une application qui, entre autres, devrait à un moment donné convertir des fichiers écrits au format ABC au format DEF. La conversion ne nécessite aucune désérialisation / sérialisation vers / depuis les objets métier, et se fait en appliquant un tas d'expressions régulières suffisamment courtes pour être placées dans la classe de conversion elle-même appeléeAbcToDefConverter
. Toute la logique de conversion prend environ 80 LLOC dans une dizaine de méthodes interdépendantes - semble être une situation où il n'est absolument pas nécessaire de diviser la classe existante, ni de créer des classes supplémentaires. Étant donné que la partie restante de l'application n'a rien à voir avec les conversions, la classe ne peut pas être regroupée avec d'autres classes dans des espaces de noms existants. On crée donc un espace de noms appelé AbcToDefConverter
. Bien qu'il n'y ait rien de fondamentalement mauvais à cela, on pourrait également utiliser un nom plus générique, tel que Converters
. Dans des langages tels que Python, où des noms plus courts sont préférés et où la répétition est lancée, cela peut même devenir converters.Abc_To_Def
.
Par conséquent, utilisez des noms différents pour les espaces de noms et pour les classes qu'ils contiennent. Le nom d'une classe doit indiquer ce que fait la classe, tandis que le nom de l'espace de noms doit mettre en évidence ce qui est commun à toutes les classes qu'il contient.
Soit dit en passant, les classes d'utilité sont fausses par nature: au lieu de contenir quelque chose de spécifique, comme l'arithmétique de précision arbitraire, elles contiennent plutôt tout ce qui n'a pas trouvé son chemin dans d'autres classes . C'est tout simplement une mauvaise appellation, tout comme un Miscellaneous
répertoire sur un ordinateur de bureau - quelque chose qui indique le manque d'organisation.
La dénomination existe pour une raison: pour vous faciliter la vie lorsque vous avez besoin de trouver des choses plus tard. Vous savez que si vous avez besoin de dessiner un graphique, vous pouvez essayer de rechercher «graphique» ou «tracé». Lorsque vous devez modifier la façon dont une application génère des factures, vous recherchez «facture [e / ing]» ou «facture». De même, essayez d'imaginer un cas où vous vous direz: "hm, cette fonctionnalité devrait probablement se trouver dans misc". Je ne peux pas.
Regardez .NET Framework. La plupart de ces classes ne sont-elles pas des classes utilitaires? Je veux dire, ils ont peu de choses à voir avec le domaine des affaires. Si je travaille sur une application financière, sur un site Web de commerce électronique ou sur la plate-forme de formation de prochaine génération, sérialiser XML ou lire des fichiers ou effectuer des requêtes SQL ou effectuer des transactions est tout ce qui est utile. Cependant, ils ne sont pas appelés UtilitySerialization
ou UtilityTransaction
et ils ne se trouvent pas dans l' Utility
espace de noms. Ils ont des noms propres, ce qui permet (et facile, merci aux développeurs .NET!) De les trouver quand j'en ai besoin.
Il en va de même pour vos cours que vous réutilisez couramment dans vos applications. Ce ne sont pas des classes d'utilité. Ce sont des classes qui font certaines choses, et les choses qu'elles font devraient en fait être les noms des classes.
Imaginez que vous avez créé du code qui traite des unités et de la conversion des unités. Vous pouvez le nommer Utility
et être détesté par vos collègues; ou vous pouvez le nommer Units
et UnitsConversion
.