Espace de nom et classe avec le même nom ?

Question

Je suis en train d'organiser un projet de bibliothèque et j'ai une classe de gestionnaire central nommée Scenegraph et tout un tas d'autres classes qui vivent dans l'espace de noms Scenegraph.

Ce que j'aimerais vraiment, c'est que le diagramme de scène soit MyLib.Scenegraph et les autres classes à être MyLib.Scenegraph.* mais il semble que la seule façon de le faire serait de faire de toutes les autres classes des classes internes de Scenegraph dans le fichier Scenegraph.cs et c'est tout simplement trop lourd.

Au lieu de cela, je l'ai organisé comme suit Mylib.Scenegraph.Scenegraph y MyLib.Scenegraph.* Cela fonctionne en quelque sorte, mais je trouve que Visual Studio ne sait pas toujours si je fais référence à la classe ou à l'espace de nom.

Existe-t-il un bon moyen d'organiser ce paquet de manière à ce qu'il soit pratique pour les utilisateurs sans pour autant rassembler tout mon code dans un fouillis impossible à maintenir ?

Answer 1

Je ne vous recommande pas de nommer une classe comme son espace de nom, cf. cet article .

Les directives de conception du Framework indiquent dans la section 3.4 "ne pas utiliser le même nom pour l'espace de noms et le type dans cet espace de noms". même nom pour un espace de noms et un type dans cet espace de noms". C'est-à-dire :

namespace MyContainers.List 
{ 
    public class List { … } 
}

Pourquoi cette méchanceté ? Oh, laissez-moi compter les raisons.

Vous pouvez vous mettre dans des situations où vous pensez que vous vous référez à une chose mais qu'en fait vous faites référence à autre chose. Supposons que vous situation malheureuse : vous écrivez Blah.DLL et importez Foo.DLL et Bar.DLL. importez Foo.DLL et Bar.DLL, qui, malheureusement, ont tous les deux un type appelé Foo :

// Foo.DLL: 
namespace Foo { public class Foo { } }

// Bar.DLL: 
namespace Bar { public class Foo { } }

// Blah.DLL: 
namespace Blah  
{   
using Foo;   
using Bar;   
class C { Foo foo; } 
}

Le compilateur donne une erreur. "Foo" est ambiguë entre Foo.Foo et Bar.Foo. C'est dommage. Je suppose que je vais corriger cela en qualifiant complètement le nom :

   class C { Foo.Foo foo; } 

Cela donne maintenant l'erreur d'ambiguïté " Foo dans Foo.Foo est ambiguë entre Foo.Foo et Bar.Foo ". Nous ne savons toujours pas ce à quoi le premier Foo se réfère, et jusqu'à ce que nous puissions le découvrir, nous nous ne prendrons même pas la peine d'essayer de comprendre à quoi le second fait référence.

Answer 2

Donner le même nom à l'espace de noms et à la classe peut perturber le compilateur, comme d'autres l'ont dit.

Comment l'appeler alors ?

Si l'espace de nom comporte plusieurs classes, trouvez un nom qui définit toutes ces classes.

Si le n'a qu'une seule classe (et donc la tentation de lui donner le même nom) nomme l'espace de nom Nom de la classe NS . C'est ainsi que Microsoft nomme ses espaces de noms, du moins.

Answer 3

Même si je suis d'accord avec les autres réponses dans ce vous ne devez pas nommer votre classe de la même façon que votre espace de noms il y a des moments où vous ne pouvez pas vous conformer à ces exigences.

Dans mon cas, par exemple, je n'étais pas la personne qui prenait cette décision et je devais donc trouver un moyen de la faire fonctionner.

Ainsi, pour ceux qui ne peuvent pas changer le nom de l'espace de noms ou le nom de la classe, voici un moyen de faire fonctionner votre code.

// Foo.DLL: 
namespace Foo { public class Foo { } }

// Bar.DLL: 
namespace Bar { public class Foo { } }

// Blah.DLL: 
namespace Blah
{
    using FooNSAlias = Foo;//alias
    using BarNSAlias = Bar;//alias
    class C { FooNSAlias.Foo foo; }//use alias to fully qualify class name
}

En fait, j'ai créé des "alias" d'espace de nom, ce qui m'a permis de qualifier complètement la classe et la "confusion" de Visual Studio a disparu.

NOTE : Vous devez éviter ce conflit de noms si vous êtes en mesure de le faire. Vous ne devez utiliser la technique mentionnée que lorsque vous ne contrôlez pas les classes et les espaces de noms en question.

Answer 4

Je vous suggère de suivre les conseils que j'ai reçus sur microsoft.public.dotnet.languages.csharp à utiliser MyLib.ScenegraphUtil.Scenegraph y MyLib.ScenegraphUtil.* .

Answer 5

Comme d'autres l'ont dit, c'est une bonne pratique d'éviter de nommer une classe de la même façon que son espace de nom.

Voici quelques autres suggestions d'attribution d'appellation de une réponse de svick à une question connexe "Même nom de classe et d'espace de nom" sur le Stack Exchange du génie logiciel :

Vous avez raison de dire que vous ne devriez pas nommer l'espace de nom de la même manière qu'un type. qu'il contient. Je pense qu'il y a plusieurs approches que vous pouvez utiliser :

• Pluraliser : Model.DataSources.DataSource

Cela fonctionne particulièrement bien si le but premier de l'espace de nom est de est de contenir des types qui héritent du même type de base ou implémentent la même même interface.

• Raccourcir : Model.QueryStorage

Si un espace de noms ne contient qu'un petit nombre de types, peut-être n'avez-vous pas du tout besoin de cet espace de noms. besoin de cet espace de noms.

• Faire de l'entreprise : Modèle.ProjetSystème.Projet

Cela peut fonctionner en particulier pour les fonctionnalités qui sont une partie importante de votre produit, de sorte qu'elles méritent leur propre nom.