c# - que - ¿Espacio de nombres y clase con el mismo nombre?

namespace my c#

Question

Estoy organizando un proyecto de biblioteca y tengo una clase de administrador central llamada Scenegraph y un montón de otras clases que viven en el espacio de nombres de Scenegraph.

Lo que realmente me gustaría es que el scenegraph sea MyLib.Scenegraph y que las otras clases sean MyLib.Scenegraph.* , Pero parece que la única manera de hacerlo sería hacer todas las otras clases internas de Scenegraph en el Archivo Scenegraph.cs y eso es demasiado difícil de manejar.

En cambio, lo he organizado como Mylib.Scenegraph.Scenegraph y MyLib.Scenegraph.* , Que funciona, pero me parece que Visual Studio se confunde bajo ciertas condiciones en cuanto a si me refiero a la clase o al espacio de nombres.

¿Hay una buena manera de organizar este paquete, por lo que es conveniente para los usuarios sin englobar todo mi código en un lío imposible de mantener?

Answer 1

Dar el mismo nombre al espacio de nombres y la clase puede confundir al compilador como han dicho otros.

¿Cómo se llama entonces?

Si el espacio de nombres tiene múltiples clases, busque un nombre que defina todas esas clases.

Si el espacio de nombres tiene solo una clase (y por lo tanto la tentación de darle el mismo nombre), nombre el espacio de nombres ClassName NS . Así es como Microsoft nombra sus espacios de nombres al menos.

Answer 2

No recomiendo que nombre una clase como su espacio de nombres, vea this .

Las Directrices de diseño del marco dicen en la sección 3.4 "no usar el mismo nombre para un espacio de nombres y un tipo en ese espacio de nombres". Es decir:

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

¿Por qué es esto malo? Oh, dejame contar las maneras.

Puede meterse en situaciones en las que cree que se está refiriendo a una cosa, pero de hecho se está refiriendo a otra cosa. Supongamos que termina en esta desafortunada situación: está escribiendo Blah.DLL e importando Foo.DLL y Bar.DLL, que, desafortunadamente, ambos tienen un tipo llamado 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; } 
}

El compilador da un error. "Foo" es ambiguo entre Foo.Foo y Bar.Foo. Gorrón. Creo que arreglaré eso calificando completamente el nombre:

   class C { Foo.Foo foo; } 

Esto ahora da el error de ambigüedad " Foo in Foo.Foo es ambiguo entre Foo.Foo y Bar.Foo ". Todavía no sabemos a qué se refiere el primer Foo, y hasta que podamos resolverlo, ni siquiera nos molestamos en tratar de descubrir a qué se refiere el segundo.

Answer 3

Solo agregando mis 2 centavos:

Tenía la siguiente clase:

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

El cliente fue escrito así:

using Foo;

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

Perdonar el error GetFoo no devuelve el resultado en lugar de usar el parámetro out, el compilador no pudo resolver el tipo de datos Foo.Bar []. Estaba devolviendo el error: no se pudo encontrar el tipo o espacio de nombres Foo.Bar.

Parece que cuando intenta compilar resolvió Foo como la clase y no encontró una barra de clase incrustada en la clase Foo. Tampoco pudo encontrar un espacio de nombres llamado Foo.Bar. No pudo buscar una barra de clase en el espacio de nombres Foo. Los puntos en un espacio de nombre NO son sintácticos. Toda la cadena es una ficha, no las palabras delimitadas por los puntos.

Este comportamiento fue exhibido por VS 2015 corriendo .Net 4.6

Answer 4

Sugeriría que sigas los consejos que obtuve en microsoft.public.dotnet.languages.csharp para usar MyLib.ScenegraphUtil.Scenegraph y MyLib.ScenegraphUtil.* .

Answer 5

CA1724: Type Names Should Not Match Namespaces ...

Básicamente, si sigue Code Analysis para la codificación adecuada, esta regla dice que no haga lo que está tratando de hacer. Code Analysis es muy útil para ayudarlo a encontrar problemas potenciales .