Namenskonventionen und Namensräume

Question

Wenn ich Objekte auf einer Ebene mit dem gleichen Namen wie Objekte auf einer anderen Ebene haben, ist es am besten, die Objektnamen mit einigen Präfix zu ändern oder neue Namespace verfügen und mit voll qualifizierten Namen auf sie beziehen? Zum Beispiel:

namespace Project1.Data 
Object Person; 

namespace Project1.Model 
Object Person; 

---

Data.Person.Name=Person.Name; 

OR 

dbPerson.Name= Person.Name; 

Answer 1

würde ich Namespaces und Namespace-Aliase verwenden, zB:

Ihre Klassen in entsprechenden Namensräume definieren:

namespace Project1.Data 
{ 
    public class Person {...} 
} 
namespace Project1.Model 
{ 
    public class Person {...} 
} 

Und wo verwenden Sie die Klassen verwenden entweder vollständig qualifizierte Namen oder definieren einen Alias ​​für die Namespaces (besonders nützlich, wenn der vollständige Namespace lang ist):

using data = Project1.Data; 
using model = Project1.Model; 

data.Person p1 = new data.Person(); 
model.Person p2 = new model.Person(); 
//... 
p1.Name = p2.Name; 

Answer 2

Es hängt davon ab, wie oft Sie auf den überladenen Namen verweisen.

Wenn Sie es mehrmals in einer Datei zu verwenden, dann die erste Art und Weise nutzen.

Wenn Sie es nur ein- oder zweimal verwenden, schreiben Sie den vollständig qualifizierten Namen, damit andere Personen nicht am Anfang der Datei herumjagen müssen, um herauszufinden, auf welches Objekt Sie sich beziehen.

Answer 3

Es hängt wirklich von der Frequenz sind Sie jeder von ihnen anfordert. Im Allgemeinen verwende ich die abgekürzte Version für den Typ, auf den ich mich am häufigsten beziehe, und verwende den längeren Namen für den Typ, der weniger häufig verwendet wird. Ich würde sagen, schließlich, wenn Sie viele Verwendungen sowohl in der gleichen Datei am Ende mit, dass Sie Namespace-Aliasing verwenden sollten, aber für mich, das ist ein letzter Ausweg nur, nachdem der Code zu einem Punkt aufgebläht hat, wo es ist schwer zu folge, was vor sich geht.

Answer 4

haben die gleich mir gedacht. Ich denke, den Namen der Klassen zu suchen ist eine schlechte Idee. Zum Beispiel habe ich eine Datenzugriffsschicht und eine Business-Schicht. Beide befassen sich mit Benutzern. So habe ich ...

Project1.Business.User Project1.DataAccess.User

zu denken erfinde neuen Namen für die Klassen versuchen, ist eine Verschwendung von Zeit und wird wahrscheinlich seltsame Namen für Klassen mit wenig bedeuten Bedeutung. Die Benennung von Klassen kann bereits Kopfschmerzen bereiten.

Ich stimme McWafflestix zu "Ich verwende die abgekürzte Version für den Typ, auf den ich mich am häufigsten beziehe, und verwende den längeren Namen für den Typ, der weniger häufig verwendet wird".

Answer 5

Es ist ganz einfach. Hören auf die .NET-Framework-Richtlinien einmal hilft tatsächlich (obwohl viel Material in dem Buch ist einfach nur Elemente des Java-Stils noch einmal in Redmond Wonderland) ..

Sie sollten ähnliche Typnamen in Cross-oder Intra-Projekt vermeiden/Bibliothek Mischen von Namespaces ie. Mischen über Domains und Modelle in generischen (auch in C++ eine, die extrem streng und mächtig ist, hat es auch eine Inkarnation in Compiler, Auflösung und Compiler Abstürze und Probleme Enum-Stil).

Daher ist sogar die vollständige Qualifizierung die ganze Zeit nicht narrensicher (und btw Aliases und 'using' sind extrem begrenzt und verursachen leichte Duplikation im besten Fall und beweisen C# Schwachstellen bei generischen Programmen usw.).

In meiner Erfahrung sind Daten Domain-Typen ein primäres Ziel für einen geeigneten Namen und damit für Namen Refactoring die lauten:

a) billig (als Prozess in der reichen Ast aber einfache adt-Unterstützung wie in C#, Rechtsklick in IDE und fühlen sich mächtig nach Typ-herausgefordert dynamische Ruby Fans/Backers)

[kann auch gelesen werden als: 4.0 dynamische Funktionen Schaf wird jeder Schuld, aber nicht über Namespaces oder funktionale JS, C denken - mit Vorlagen (nicht C-mit-Klassen) oder ähnlich]

b) kommuniziert die Semantik besser ie. die Absicht (dh Klempnerarbeit + Unterstützung, um deine eigene Verarbeitung aufzubauen)

c) normalerweise von primitiver, aber getippter Natur oder Nachricht (nicht OO geschrieben; dh OO-artige Kritik wie im oben erwähnten Buch, das selbst gerade aus dem Intro bricht Aufzüge alle 'Model' land)

d) und 'Aliasing' verweisen werden ein nützliches Artefakt in domänenübergreifende Nutzung (was tatsächlich möglich ist und ganz 2020-like .. dh. Wert-Typ Programmierung)

Es gibt wirklich keine Regeln, aber hüte dich davor, dass du Namespaces in der Entwicklung mischen wirst, wenn es am wenigsten erwartet wird. Das bedeutet nur eine Sache für einen gemanagten Entwickler: Verwirrung. Plus etwas weniger ernst, mehr Kompilierungszeit und IntelliNonsense Fehler natürlich.

Tough Problem in allen Sprachen, so ist es Ihr Design/Naming Problem .. Auch Werkzeugverkäufer können für Maschinen zu parsieren vermasseln .. sagen Ausgabe von erweiterten populären IDEs basierend auf veralteten Browse-Informationen; dann wieder, andere tun es wirklich gut für gemanagte Sprachen.

Nicht, dass ich gegen doppelte Namen bin, gibt es Fälle (sie sind hart aber notwendig), wenn Dual + Interop + Repräsentation usw. andere Modelle mischen, wo der gleiche Name es lesbarer macht; dh. wo Duplikation ist eine Notwendigkeit der Dual-Usage .. aber das ist niedriger Ebene Idiome, die C# ist nicht freundlich oder ermutigend (re: zugunsten Overhead).