Namespace e classe con lo stesso nome?

Question

Sto organizzando un progetto di libreria e ho una classe di gestore centrale denominata Scenegraph e un gruppo di altre classi che vivono nello spazio dei nomi di Scenegraph.

Quello che mi piacerebbe davvero è per scenegraph di essere MyLib.Scenegraph e le altre classi di essere MyLib.Scenegraph.*, ma sembra l'unico modo per farlo sarebbe quello di fare tutte le altre classi classi interne di Scenegraph nel scenegraph. file cs e questo è troppo pesante.

Invece, l'ho organizzato come Mylib.Scenegraph.Scenegraph e MyLib.Scenegraph.*, che tipo di opere, ma trovo Visual Studio viene confuso in alcune condizioni se mi riferisco alla classe o lo spazio dei nomi.

C'è un buon modo per organizzare questo pacchetto in modo che sia conveniente per gli utenti senza gettare tutto il mio codice insieme in un pasticcio non gestibile?

Answer 1

Non consiglio di denominare una classe come il suo spazio dei nomi, vedere this.

The Framework Design Guidelines say in section 3.4 “do not use the same name for a namespace and a type in that namespace”. That is:

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

Why is this badness? Oh, let me count the ways.

You can get yourself into situations where you think you are referring to one thing but in fact are referring to something else. Suppose you end up in this unfortunate situation: you are writing Blah.DLL and importing Foo.DLL and Bar.DLL, which, unfortunately, both have a type called 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; } 
} 

The compiler gives an error. “Foo” is ambiguous between Foo.Foo and Bar.Foo. Bummer. I guess I’ll fix that by fully qualifying the name:

class C { Foo.Foo foo; } 

This now gives the ambiguity error “Foo in Foo.Foo is ambiguous between Foo.Foo and Bar.Foo”. We still don’t know what the first Foo refers to, and until we can figure that out, we don’t even bother to try to figure out what the second one refers to.

Answer 2

CA1724: Type Names Should Not Match Namespaces ...

In sostanza, se si seguono analisi del codice per una corretta codifica questa regola dice di non fare wha t stai cercando di fare. L'analisi del codice è molto utile per aiutare a trovare potenziali problemi.

Answer 3

Suggerisco di seguire il consiglio che ho ricevuto su microsoft.public.dotnet.languages.csharp per utilizzare MyLib.ScenegraphUtil.Scenegraph e MyLib.ScenegraphUtil.*.

Answer 4

semplicemente aggiungendo i miei 2 centesimi:

ho avuto la seguente classe:

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

Il client è stato scritto così:

using Foo; 

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

Perdonare l'errore non getFoo restituendo l'output invece di usare il parametro out, il compilatore non ha potuto risolvere il tipo di dati Foo.Bar []. Restituiva l'errore: impossibile trovare il tipo o lo spazio dei nomi Foo.Bar.

Sembra che quando tenta di compilarlo ha risolto Foo come classe e non ha trovato una barra di classe incorporata nella classe Foo. Inoltre non è stato possibile trovare uno spazio dei nomi chiamato Foo.Bar. Non è riuscito a cercare una barra di classe nel namespace Foo. I punti in uno spazio dei nomi NON sono sintattici. L'intera stringa è un token, non le parole delimitate dai punti.

Questo comportamento è stato esibito da VS 2015 in esecuzione .Net 4.6

Answer 5

Dare lo stesso nome per lo spazio dei nomi e la classe può confondere il compilatore come altri hanno detto.

Come si chiama?

Se lo spazio dei nomi ha più classi, trovare un nome che definisca tutte quelle classi.

Se lo spazio dei nomi ha solo una classe (e quindi la tentazione di dargli lo stesso nome) il nome del namespace NomeClasse NS. Questo è il modo in cui Microsoft nomina almeno i loro spazi dei nomi.