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

Scenegraph 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 de Scenegraph.

Ce que je voudrais vraiment, c’est que le MyLib.Scenegraph soit MyLib.Scenegraph et que les autres classes soient MyLib.Scenegraph.* , Mais il semble que la seule façon de le faire soit de faire toutes les classes internes de Scenegraph dans le Fichier Scenegraph.cs et c’est trop compliqué.

Au lieu de cela, je l’ai organisé comme Mylib.Scenegraph.Scenegraph et MyLib.Scenegraph.* , Ce qui fonctionne, mais je trouve que Visual Studio est confondu dans certaines conditions quant à savoir si je fais référence à la classe ou à l’espace de noms.

Existe-t-il un bon moyen d’organiser ce package de manière à ce qu’il soit pratique pour les utilisateurs qui ne regroupent pas tout mon code dans un désordre intenable?

Je ne vous recommande pas de nommer une classe comme son espace de noms, voir ceci .

Les directives de conception du cadre disent à la section 3.4 «n’utilisez pas le même nom pour un espace de noms et un type dans cet espace de noms». C’est:

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

Pourquoi cette méchanceté? Oh, laisse-moi compter les moyens.

Vous pouvez vous retrouver dans des situations où vous pensez faire référence à une chose, mais en fait, vous faites référence à autre chose. Supposons que vous vous retrouviez dans cette situation malheureuse: vous écrivez Blah.DLL et importez Foo.DLL et Bar.DLL, qui, malheureusement, ont tous 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. Dommage. Je suppose que je vais résoudre ce problème 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 soaps toujours pas à quoi le premier Foo fait référence, et jusqu’à ce que nous puissions comprendre cela, nous ne prenons même pas la peine d’essayer de comprendre à quoi le second fait référence.

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

CA1724: Type Names Should Not Match Namespaces

Fondamentalement, si vous suivez l’parsing du code pour un codage correct, cette règle dit de ne pas faire ce que vous essayez de faire. L’parsing de code est très utile pour vous aider à trouver des problèmes potentiels .

Donner le même nom à l’espace de noms et à la classe peut confondre le compilateur avec d’autres.

Comment le nommer alors?

Si l’espace de noms comporte plusieurs classes, recherchez un nom définissant toutes ces classes.

Si l’ espace de noms n’a qu’une classe (et donc la tentation de lui donner le même nom), nommez l’espace de noms ClassName NS . Voici comment Microsoft nomme ses espaces de noms au moins.

Il suffit d’append mes 2 cents:

J’ai eu la classe suivante:

 namespace Foo { public struct Bar { } public class Foo { //no method or member named "Bar" } } 

Le client a été écrit comme ceci:

 using Foo; public class Blah { public void GetFoo( out Foo.Bar[] barArray ) { } } 

En oubliant l’erreur GetFoo ne renvoyant pas la sortie au lieu d’utiliser le paramètre out, le compilateur n’a pas pu résoudre le type de données Foo.Bar []. Il retournait l’erreur: impossible de trouver le type ou l’espace de noms Foo.Bar.

Il semble que quand il essaie de comstackr, il a résolu Foo en tant que classe et n’a pas trouvé de classe intégrée Bar dans la classe Foo. Il ne pouvait pas non plus trouver un espace de noms appelé Foo.Bar. Il n’a pas réussi à rechercher une classe Bar dans l’espace de noms Foo. Les points dans un espace de nom ne sont PAS syntaxiques. La chaîne entière est un jeton, pas les mots délimités par les points.

Ce comportement a été présenté par VS 2015 exécutant .Net 4.6