Hiérarchie de namespaces

Bonjour à tous,
Comment organiser son projet dans une hiérarchie cohérente d'espace de nommage succeptible d'etre souvent revue ?

La forme générale pourrait ressemblerait par exemple à ceci:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

root{ a{ classe1 classe2 } b{ classe3 } c{ d{ classe4 } } }

---

Actuellement je me suis dis que je pourrais faire ceci (mais j'ai l'impression que ce n'est pas possible) :

classe1.h:

Code:

---

1 2 3 4 5 6 7 8

class classe1{ ... }   namespace a{ class classe1; }

---

idem pour les autre headers, ex classe4.h

Code:

---

1 2 3 4 5 6 7 8

class classe4{ ... }   namespace d{ class classe4; }

---

ensuite j'imagine un fichier .h quelconque reprenant la hiérarchie des namespace que j'espere pouvoir "modeler" comme je veux, par exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

namespace root{ namespace a{}; namespace b{}; namespace c{ namespace d{}; }; }   // et pour finir faire des alias sur les namespaces pour qu'ils soient moins //rébarbatifs qu'en interne (le but et de rester le plus libre face au noms et a //l'organisation des namespaces)   //genre : namespace racine = root; namespace employes = a; namespace batiments = b; namespace utilitaires = c; namespace base = d;

---

est ce que dans ce cas une ligne du type :

Code:

---

1 2	racine::utilitaires::base::classe4 varc4;

---

serait valide ?

Merci de bien vouloir m'éclairer un peu parce que ceci est un peu obscur pour moi ;-)

Salut,

L'idée des espaces de noms, c'est de regrouper "dans un même sac" les différents types et fonctions "qui vont bien ensemble" (comprend ici qui poursuivent un même but).

Il se fait que j'ai justement fait une intervention sur les thème des espaces de noms, qui, bien que le but premier était d'expliquer la raison qui devait inciter les gens à l'utiliser, me semble tout à fait adaptée pour répondre à ta question.

Comme cette intervention est assez longue, tu m'excusera de ne te donner que le lien ;) elle se trouve ==>ici<==

Salut,
tout d'abord merci pour ta réponse.
En fait je savais qu'un namespace agissait comme un "sac" ou sont rangées ensembles les classes qui doivent l'etre.

Avec cet exemple ce que j'aurais aimé faire c'est de changer les imbrications des namespaces entre eux le plus facilement (grace à un seul fichier, celui qui décrit la hierarchie ; par exemple).

J'ai fais quelques test mais ça n'a pas donné grand chose mais peut etre m'y suis-je mal pris aussi.

Actuellement (et corrige-moi si ce n'est pas la bonne façon de procéder) je m'amuse pour chaque classe a la définir dans une imbrication précise de namespaces. Et que donc à prioris, si il faut faire une modification de la hierarchie il faudra la faire pour toutes les classes associées, donc tout les .h :(

Code:

---

1 2 3 4 5 6 7 8

namespace niveau1{ namespace niveau2{ class maclasse{ ... } } }

---

Voila c'est lourd de ramener ma classe dans un niveau3 par exemple (surtout si il faut le refaire pour d'autres dizaines de classes)

Mais c'est la configuration que j'ai actuellement, donc déja dans un premier temps faut-il forcément réimbriquer "maclasse" dans ses 2 ou 3 niveaux dans son fichier .h ou il y a plus simple ?

Ensuite pour en revenir a ma question principal existe-t-il une façon de faire pour changer la hierarchie des namespace "à la volée" on va dire (donc, genre une modif dans un fichier) ?

Ce qu'il faut bien que tu comprenne, c'est que l'ordre logique de travail, c'est de commencer par analyser "aussi aussi loin que possible", à l'aide d'un simple papier et d'un crayon, ce dont ton application a besoin.

Tout le monde te dira que, de toutes façons, les besoins de l'application

• ne sont jamais complets
• changent tout le temps
• nous sont souvent cachés par le simple fait que l'utilisateur final "pense que, mais bon sang, sa va de soi"

Mais il n'empêche que, si tu ne pars pas avec une analyse minimale, ton projet va droit dans le mur.

L'analyse consiste, principalement, à répondre à quatre questions:

1. Quel est le but de mon application (ou de ma bibliothèque) :question:
2. De quelles informations mon application (ou ma bibliothèque) a-t-elle besoin :question:
3. Où (et comment) mon application (ou ma bibliothèque) va-t-elle obtenir ces information :question:
4. Quel(s) traitement(s) mon application va-t-elle faire subir à ces informations :question:

Autant le dire tout de suite, tant que tu n'a pas une réponse "aussi claire et précise que possible" à l'une de ces questions, il n'est même pas nécessiare de vouloir passer à la question suivante.

Et il ne sert pour ainsi dire qu'à perdre du temps d'essayer de commencer l'écriture de ton code, tant que tu n'a pas au minimum une réponse acceptable à ces quatre questions.

Ces questions vont, presque "naturellement", t'amener à envisager, entre autres, une série de structures de données, couplées à une série de "messages" que ces structures peuvent envoyer ou auxquels ces structures vont devoir réagir.

En gros, tu va finir par obtenir ce que l'on appelle en UML un diagramme de classes (et sans doute une série d'autres diagrammes, qui s'inscriront dans ta méthode d'analyse préférée ;)).

Et tu remarquera que tes différentes classes présentent une série de relations entre elles:

• Certaines classes contiennent un certain nombre d'autres classes
• Certaines héritent d'une (ou de plusieurs) autre(s) classe(s)
• Certaines utiliisent une (ou plusieurs) autre(s) classe(s) pour parvenir à leur but
• Certaines poursuivent un "même but générique" (par exemple: envoyer des informations sur le réseau)

C'est à partir de ces constatations que tu va décider de regrouper ces différentes classes entre elles en espaces de noms.

Il faut bien comprendre que les décisions importantes (comme par exemple la hiérarchie des espaces de noms) sont donc prises bien avant d'écrire la première ligne de code.

Si ton analyse a correctement été menée, et malgré le fait que certains aspects puisent apparaitre en cours de développement (nécessitant de reprendre une partie de l'analyse), il est fort vraisemblable que les adaptations ne nécessitent pas de révision en profondeur de la hiérarchie d'espaces de noms.

Ce qui risque fort de se passer, c'est que tu remarque avoir oublié quelque chose lorsque tu commence à écrire ton code, ou que tu te rende compte n'avoir absolument pas pris un besoin en compte.

Il est fort vraisemblable que tu décide de rajouter, de retirer ou de modifier des classes, ou encore de modifier certaines relations existant entre deux (ou plusieurs) classes, mais l'organisation générale des espaces de noms sera sans doute ce qui sera le plus stable dans le temps...

Et la raison en est simple: tu prend la décision de "saucissonner" ton projet en espaces de noms (en "paquetages")... sur base de l'ensemble des relations qui régissent les classes que tu as déterminées.

S'il se peut (et, si l'analyse est correcte, le risque est très faible) que tu sois tenté de modifier la hiérarchie des espaces de noms, ce seront le plus souvent des modifications qui n'impliquent qu'un nombre restreint de classes ;)

Je met un gros +1 sur ton post ! ;)

Je ne vois pas trop de moyen simple et propre de faire ce genre de choses. Je verrais deux directions :
- Tu mets chaque classe sans aucun namespace dans son fichier, et tu as un gros fichier, qui est le seul à être compilé, et qui inclue tous les autres (tu perds donc la compilation séparée...).

Code:

---

1 2 3 4 5 6 7 8 9 10 11

namespace a { namespace b { #include "class1.h" } namespace c { #include "class2.h" } namespace b { #include "class1.cpp" } }

---

- Tu défini dans un fichier unique des macros qui représentent les namespaces

Code:

---

1 2 3 4 5 6

#define CLASS1_NAMESPACE_START namespace a{namespace b { #define CLASS1_NAMESPACE_STOP } }   CLASS1_NAMESPACE_START class1 {...}; CLASS1_NAMESPACE_STOP

---

Dans les deux cas, le code client n'est pas franchement protégé des changements.

Mais bon, à la base, j'ai envie de dire que les namespaces sont souvent une choses assez stable, qui ne demande pas à être changés trop souvent. J'ai tendance à avoir un namespace et un seul par bibliothèque (voire des namespace partagés entre plusieurs bibliothèque de même niveau), une granularité plus fine ayant peu d'intérêt en général je pense. Donc si je veux changer ça, c'est que je change l'organisation de mes bibliothèques, et donc je suis déjà dans une phase de modification lourde, ce n'est donc pas les namespaces qui vont poser problème.

Pour pallier ce problème, il est toujours possible de faire confiance à la puissance de ton EDI (ou de quelques instructions bien senties sous linux), qui peut le plus souvent effectuer des remplacements dans plusieurs fichiers, voir dans tous les fichiers d'un projet.

Ainsi, tu devrais pouvoir faire remplacer toute une imbrication d'espace de noms dans l'ensemble des fichiers, seule serait éventuellement à ta charge de les enregistrer ;)

Cependant, cela peut nécessiter une hygiène de codage relativement stricte, entre autres, au niveau des indentations.

Pour la clôture des espaces de noms (l'accolade fermante correspondante), tu peux faciliter le travail de ton EDI avec une habitude toute simple: placer en argument le nom de l'espace de noms auquel elle correspond.

Ainsi, j'ai pris l'habitude d'écrire mes codes sous la forme de

Code:

---

1 2 3 4 5 6 7

namespace Truc { namespace Brol { /*...*/ }//namespace Brol }//namespace Truc

---

Si, pour une raison ou une autre, je venais, pour avoir repris ma conception à zéro, à décider de changer l'imbrication des espaces de noms, il me "suffirait" de lancer deux recherches/modifications dans mon edi.

La première porterait sur

Code:

---

1 2 3 4

namespace Truc { namespace Brol {

---

la deuxième porterait sur

Code:

---

1 2 3

}//namespace Brol }//namespace Truc

---

les deux étant à appliquer sur l'ensemble des fichiers du projet ;)