Règles de nommage et d'utilisation des espaces de noms c ++

Question

Sur le projet, nous essayons de nous entendre sur l’utilisation de l’espace de nommage. Nous avons décidé que le premier niveau serait " productName " et le second est "moduleName".

productName::moduleName

Maintenant, si le module est un genre de module utilitaire, il n'y a pas de problème pour ajouter un troisième espace de noms. Par exemple, ajouter " str " ;: productName :: utilityModuleName :: str - pour diviser un espace où toutes les & str; chaînes " trucs connexes ira.

Si le module est le module métier principal, nous avons beaucoup d'opportunités et presque aucun accord.

Par exemple

class productName::mainModuleName::DomainObject

et

class productName::mainModuleName::DomainObjectSomethingElseViewForExample

peut être à la fois à

namespace productName::mainModuleName::domainObject
class Data
class ViewForExample

Pourquoi devrions-nous créer des classes internes non privées et non des espaces de noms? Pourquoi devrions-nous créer une classe où toutes les méthodes sont statiques (sauf les cas où cette classe sera un paramètre template)?

Le projet consiste en 1 Go de code source. Alors, quelle est la meilleure pratique pour diviser les modules sur les espaces de noms dans le c ++?

Answer 1

À quoi servent les espaces de nom:

Les espaces de noms sont destinés à établir un contexte uniquement afin que vous ne disposiez pas de confilts de nommage.

Règles générales:

Spécifier trop de contexte n'est pas nécessaire et causera plus d'inconvénients que cela ne vaut.

Vous souhaitez donc utiliser votre meilleur jugement, tout en respectant ces 2 règles:

• Ne soyez pas trop général lorsque vous utilisez des espaces de noms
• Ne soyez pas trop spécifique lorsque vous utilisez des espaces de noms

Je ne serais pas aussi strict sur la façon d'utiliser les noms d'espace de nom et d'utiliser simplement des espaces de nom basés sur un groupe de code associé.

Pourquoi les espaces de noms trop généraux ne sont pas utiles:

Le problème avec la division de l'espace de noms en commençant par le nom du produit est que vous aurez souvent un composant de code ou une bibliothèque de base commune à plusieurs produits.

Vous n'utiliserez pas non plus d'espaces de nom Product2 dans Product1, il est donc inutile de le spécifier explicitement. Si vous incluez les fichiers de Product2 dans Product1, cette conversion de noms est-elle toujours utile?

Pourquoi les espaces de noms trop spécifiques ne sont pas utiles:

Lorsque vous avez des espaces de noms trop spécifiques, la ligne entre ces espaces de noms distincts commence à s'estomper. Vous commencez à utiliser les espaces de noms les uns dans les autres. À ce stade, il est préférable de généraliser le code commun sous le même espace de noms.

Classes avec tous les modèles vs statiques:

  

" Pourquoi devrions-nous créer un pas interne?   des cours privés et non des espaces de noms?   Pourquoi devrions-nous créer des classes où tous   les méthodes sont statiques "

Quelques différences:

• Les espaces de noms peuvent être implicites en utilisant le en utilisant mot clé
• Les espaces de noms peuvent être aliasés, les classes sont des types et peuvent être typées
• Les espaces de noms peuvent être ajoutés à; vous pouvez y ajouter des fonctionnalités à tout moment et y ajouter directement
• Les classes ne peuvent pas être ajoutées sans créer une nouvelle classe dérivée
• Les espaces de noms peuvent avoir des déclarations en aval
• Avec les classes, vous pouvez avoir des membres privés et des membres protégés
• Les classes peuvent être utilisées avec des modèles

Comment diviser exactement:

  

"Projet composé de 1 Go de source   code. Alors, quelle est la meilleure pratique pour   diviser les modules sur les espaces de noms dans le   c ++? "

Il est trop subjectif de dire exactement comment diviser votre code sans le code source exact. La division en fonction des modules semble logique, mais pas le produit dans son ensemble.

Answer 2

Tout cela est subjectif, mais j’hésiterais à aller à plus de 3 niveaux. Cela devient trop compliqué à un moment donné. Donc, à moins que votre base de code soit très, très volumineuse, je la garderais assez superficielle.

Nous divisons notre code en sous-systèmes et avons un espace de noms pour chaque sous-système. Les objets utilitaires iraient dans leur propre espace de noms s'ils étaient effectivement réutilisables dans des sous-systèmes.

Answer 3

Il me semble que vous essayez d'utiliser les espaces de noms en tant qu'outil de conception. Ils ne sont pas destinés à cela, ils sont destinés à empêcher les conflits de noms. Si vous n’avez pas les conflits, vous n’avez pas besoin des espaces de noms.

Answer 4

Je divise les espaces de noms en fonction de ses utilisations:

J'ai un espace de noms séparé dans lequel j'ai défini toutes mes interfaces (classes virtuelles pures).

J'ai un espace de noms séparé, où j'ai défini mes classes de bibliothèque (comme db library, processing library).

Et j'ai un espace de noms séparé, où j'ai mes objets de base métier (logique métier) (tels que Purchase_order, etc.).

Je suppose qu’il s’agit de le définir d’une manière qui ne devient pas difficile à gérer à l’avenir. Ainsi, vous pouvez vérifier les difficultés qui vous entoureront sur votre conception actuelle.

Et si vous pensez qu'ils vont bien, vous devriez y aller.