Discussion :

[tribaleur]

Bonjour à tous,

Je n'ai jusqu'à maintenant jamais vraiment utilisé les namespaces. Mais dans le cadre d'un projet perso (client lourd), j'ai besoin de déclarer des enum qui doivent être accessibles depuis plusieurs autres classes du projet. Après recherche, les namespaces me semble la solution.

Pour le moment j'ai trois enum avec 4-5 valeurs dans chaque, je n'ai donc déclaré qu'un namespace qui ne contient que ces enum. J'appelle ensuite ce namespace avec une instruction using dans les déclaration de mes classes qui ont besoin de ces enum. Mais j'ai le doute, est-ce que je ne prends pas un char pour taper sur une mouche ?

Quels sont donc les bonnes pratiques avec namespace ?
Si j'ai besoin de déclarer plusieurs classes dans un même namespace, mais que je souhaite déclarer chaque classe dans un fichier à part, quelle est la solution ?
Est-ce qu'il est conseillé de déclarer toutes mes classes dans un ou des namespaces ? Pourquoi ?
Est-ce que ça change quelque chose lors de la compilation ou est-ce que c'est plus pour une question de cohésion du code ?

Je pensais avoir compris ce qu'est un namespace. Mais après approfondissement j'ai l'impression que c'est plus complexe qu'il n'y parait.

Du coup je me tourne vers vous pour profiter de vos lumières.

D'avance merci pour vos retours !

[popo]

Le namespace sert à déclarer une portée qui contient un ensemble d'élément connexes (qui sont sensés fonctionner ensemble ou représentent le même domaine fonctionnel)
Dedans tu peut y déclarer aussi bien des classes que des énumérations, des interfaces, des structures, et des délégués.

En règle général, c'est une mauvaise idée de déclarer un namespace par fichier car tu perd son intérêt principal (grouper dans une portée).

Par défaut Visual Studio créer un namespace par défaut qui est inscrit dans ton projet.
Lorsque tu créer un fichier CS dans un répertoire, le namespace de ce fichier est automatiquement celui définit dans ton projet suivi d'un point, lui même suivi par le nom du dossier.

Exemple : Mon projet s'appelle "Popo" :
- Mon namespace par défaut sera "Popo"
- Tous les fichiers CS déclaré dirctement à la racine de mon projet auront par défaut le namespace "Popo".
- Si je crée un répertoire "Tools" à la racine de mon projet, et un nouveau fichier CS à l'intérieur de ce répertoire, son namespace sera par défaut sera "Popo.Tools"
- Si je crée un répertoire "Extensions" dans "Tools", et un nouveau fichier CS à l'intérieur "Extensions", son namespace sera par défaut sera "Popo.Tools.Extensions"
- Etc.

Déclarer une classe par fichier est en règle général une bonne pratique car ça facilite la recherche.
Si tu déposes ces deux fichiers dans le même répertoires, ils auront automatiquement par défaut le même namespace.

Par contre, il n'est pas judicieux de déclarer l'intégralité de tes classes sous le même namespace à moins qu'elle couvrent toutes le même domaine fonctionnel.
La difficulté réside dans le découpage. Par exemple dans le framework .Net il y beaucoup de namespace qui commencent par System mais un découpage est réalisé selon le domaine fonctionnel qu'il couvre :
- System.Data contient des composants pour gérer des données, il est lui même découpé en Sytem.Data.Sql, System.Data.Oracle, ect. pour gérer différentes sources de données
- System.Net contient des composants pour gérer des protocoles réseau, il est lui-même découpé en System.Net.Http, System.Net.Mail, etc.

Pour la compilation, ça ne change pas grand chose que tes éléments soient déclaré dans plusieurs namespace ou dans un seul.

Si tu souhaite qu'on taide sur le choix des noms de tes namespaces ou de leur découpage, il faudra nous en dire plus sur tes classes et tes énumérations

[tribaleur]

Bonjour Popo et merci pour ces explications !

Du coup ça confirme ce que j'avais compris au départ : Les namespaces servent principalement à organiser sont code et à contrôler la porter de ses classes / struct / enum / ...

Je ne savais pas cependant pour la création "automatique" de namespace en fonction des répertoires où tu ranges tes classes dans ton projet. C'est intéressant à savoir même si je ne suis pas sûr d'en comprendre l'intérêt.

Concernant mon projet, il s'agit d'un jeux de type RPG dans lequels j'aurai besoin de plusieurs Enum. Voici la liste des Enum avec pour chacun les classes qui en ont besoin :

-EffectType {dommage, heal, shield, buff, cc, ... } => Spell, Character
-DamageType {Physical, Magical, ... } => Spell, Character
-TargetType {Ally, Ennemy, Self, ... } => Spell, Character
-RarityType {Common, Uncommon, Rare, Epique, ... } => Item, Item_Gear, Gear_Weapon

Cependant plus j'y réfléchi et plus je me dit qu'il y a peut-être moyen de supprimer ces Enum en passant par du polymorphisme. Mais d'un autre côtés est-ce que ce n'est pas compliquer les choses pour pas grand chose ? Et en l'état je ne suis pas sûr de ne pas avoir besoin de ces Enum quand même malgré le polymorphisme.

Pour info également j'ai légèrement simplifié car notamment pour les sort, il y a une gestion plus complexe mais qui est encore en cours de construction. C'est d'ailleurs ces spell qui m'ont poussé à aborder sérieusement le sujet

Qu'en pense-tu ?

[popo]

Effectivement, passer par des classes plus spécialisées et faire du polymorphisme est un pas certain vers la souplesse.
Attention toutefois à ne pas vouloir tout découper car ça peux vite devenir ingérable.
Mais pour le moment ça ne semble pas être le bazar

Moi je garderai ces énumérations.
Elle pourraient servir à pour potentielle factory.

De ce que j'ai compris :
- TargetType : est fortement lié à la notion de personnage, je déclarerais ce qui lié fortement au personnage dans un même namespace (genre Characters)
- RarityType : est fortement lié à des objets, déclarerais un namespace pour tout ce qui fortement lié au objets (genre Items)
- EffectType et DammageType sont lié à des sorts, mais je ne sais pas s'il s'agit d'un objet ou non. S'il s'agit d'un objet, il pourrait être déclaré dans un sous-namespace (genre Item.Spells), dans le cas contraire, je declarerais un namespace à part entière pour les sorts (genre Spells). On pourrait être tenté de séparer les types de sorts physique et magique dans deux sous-namespace Spells.Physical et Spells.Magical mais attention au surdécoupage. Ne le faire que si ça a un réel intérêt.

[tribaleur]

Bonjour Popo et encore merci pour ton aide !

Alors c'est en effet tout mon débat intérieur : est-ce que le découpage apporte vraiment quelque chose ? Après mure réflexion, je pense faire du polymorphisme pour les spells. Par contre je vais quand même garder les ENUM en effet car je pense avoir besoin de certains dans une interface.

Du coup je pense partir en effet sur un namespace Character avec Typetarget.
Je vais également faire un namespace Spell pour les DammageType et EffectType.
Et un dernier namespace pour les Items.

En fait j'avais déjà découpé comme ça mes script en les rangeant dans des sous dossiers de mon projet.

Du coup si j'ai bien compris :
Dans mon répertoire Spells, je créé un fichier NSSpell.cs qui comportera la déclaration du namespace "Spells" avec mon Enum déclaré dedans.
Du fait que mes autres srcips lié aux sorts sont rangés dans un dossier qui a le même nom que le namespace, ils seront donc naturellement déclaré dans le même namespace que mon Enum.

Est-ce que j'ai bien compris ton explication ?

[popo]

Du coup si j'ai bien compris :
Dans mon répertoire Spells, je créé un fichier NSSpell.cs qui comportera la déclaration du namespace "Spells" avec mon Enum déclaré dedans.
Du fait que mes autres srcips lié aux sorts sont rangés dans un dossier qui a le même nom que le namespace, ils seront donc naturellement déclaré dans le même namespace que mon Enum.

Est-ce que j'ai bien compris ton explication ?

Tes fichiers auront tous le même namespace si tu les déclares tous dans le même répertoire.
Attention toutefois, si tu déplaces certains fichiers après coup, ça changera pas leurs namespaces (le namespace est attribué lors de la création du fichier)