Namenskonventionen für gute Namensräume

Question

Ich erstelle eine Klassenbibliothek für eine CRUD-Geschäftsanwendung. Die wichtigsten „Kategorien“ von Business-Objekten (mit zugehörigen Datenzugriffsschicht-Objekten) sind:

• Wartung (für mit Master-Arbeit Tabellen (Masterlisten) in der Datenbank
• Vorfälle (die meisten Objekte zu einem echten beziehen -world Vorfall)
• Search (offensichtlich)

Ab sofort sind meine Namensräume wie folgt festgelegt:

• BusinessObjects.Maintenance.Contacts
• BusinessObjects.Maintenance.Products
• BusinessObjects.Maintenance.Classifications
• .
• BusinessObjects.Incidents.Contacts
• BusinessObjects.Incidents.Products
• BusinessObjects.Incidents.Classifications
• .
• BusinessObjects.Search.Contacts
• BusinessObjects.Search.Products
• BusinessObjects.Search.Classifications
• .
• Dal.Maintenance.Contacts
• Dal.Maintenance.Products
• Dal.Maintenance.Classifications
• .
• Dal.Incidents.Contacts
• Dal.Incidents.Products
• Dal.Incidents.Classifications
• .
• Dal.Search.Contacts
• Dal.Search.Products

Beachten Sie, dass jede Klasse mit dem gleichen Namen endet.

Ist das eine gute Form?

Gibt es Probleme, die aus dieser Namespace-Konvention entstehen können? Irgendwelche mögliche Verwirrung zu einer anderen Person, die diesen Code sucht/benutzt?

Ich weiß, dass im Formularcode ein Nachteil sein wird, dass ich alle Objekte mit dem Namespace qualifizieren muss. Das ist für mich keine große Sache. Gewöhnlich bevorzuge ich ein wenig Explizitheit, wenn das ein Wort ist.

Answer 1

Es scheint mir trotzdem ok. Ich würde mich jedoch von Abkürzungen fernhalten, das würde verwirren und die Leute zwingen, die Abkürzungen zu kennen oder nachzuschlagen. Auch sie werden unlesbar und unaussprechlich.

"Lets take a look at the BusObjConfIntContYYYYmmdd package now..." 

Ein Problem, das Sie den Weg laufen könnte, ist Name mit feinen Unterschieden. Da die Länge der Namen ein mögliches Problem ist, könnten Ihre Augen die ganze Sache beschönigen und nur einen Teil davon aufnehmen. Würde es jemals einen Fall geben, wo dies passiert ?:

BusinessObjects.Incidents.Classifications 
BusinessObjects.Classifications.Incidents 

oder

BusinessObjects.Forms.ProjectManager.Exportable.Windows.XP 
BusinessObjects.Forms.ProductManager.Exportable.Windows.XP 

Das erfundene Beispiel zu einem Problem werden könnte.

Answer 2

Ich denke, das Projekt würde von ein bisschen Abkürzung profitieren. Wenn ich in der Vergangenheit auf Probleme wie diese gestoßen bin, widme ich in der Regel ein wenig Dokumentation, um ein paar Abkürzungen zu erklären, die als Namespaces dienen. Normalerweise beschränke ich diese verkürzten Namen auf 3-5 Zeichen.Das trägt nicht nur zur allgemeinen Lesbarkeit des Codes im Formularcode bei, sondern ich habe auch festgestellt, dass die kürzeren Namen zu weniger Verwirrung bei anderen Programmierern führen.

Ich hoffe, dass hilft. Am Ende des Tages hängt es wirklich nur von den Vorlieben deines Teams ab ...

Answer 3

Nachdem wir dies viel durchgespielt haben, versuchen wir, die Anzahl der Namespaces niedrig zu halten (weniger als ein paar Dutzend für ein sehr großes Projekt) und die Tiefe der Namespaces kurz (weniger als 5 oder so). Aus Verbrauchssicht (Entwickler, die unsere Codebasis verwenden) ist es ein Overhead mit sehr geringem Nutzen, eine große Anzahl von Namespaces mit wenigen Klassen verfolgen zu müssen.

Wir gruppieren auch gerne mit Like, basierend auf der Nutzung. Wenn ein Entwickler ziemlich wahrscheinlich immer bestimmte Klassen in Verbindung mit anderen verwendet, auch wenn (in Ihrem Beispiel) eine Beziehung zu Maintenance und die andere nicht, wenn sie logisch, operativ oder prozedural verwandt sind, wir sie in den gleichen Namespace setzen . Die Funktionalität, die separat ist (z. B. wartungsspezifische Logik), wird mithilfe eines Providermodells in einen anderen Namespace aufgeteilt. Da ein Entwickler die providerenthaltende Funktionalität weniger wahrscheinlich ändern muss, ist dies in einem tieferen, separaten Namespace erforderlich.

Answer 4

Ich benutze einen Namespace pro Bibliothek und einen pro ausführbaren Quellcode. Die Namen sind immer kurz. Zum Beispiel in den ausführbar ich gerade arbeite, ich habe:

• Alib - meine allgemeine Utility-Bibliothek
• Mongo - meine Mini-Web-Server-Bibliothek
• DBLite - mein SQLite3 & einfache Persistenz-Wrapper Schicht
• Track1 - ausführbare Datei (eigentlich ein paar Executables)

Dies scheint ziemlich gut zu funktionieren. Ich finde, dass sehr komplexe Namespace-Schemata vermieden werden sollten, genauso wie sehr komplexe, tiefgreifende Hierarchien.

Answer 5

Ihre Namespacehierarchie ähnelt einer Bedingung, die als verschachtelte Generalisierung bezeichnet wird. Dies ist, wenn Sie Klassen haben, die mehrere verschiedene Wege ableiten.

eine Klassenhierarchie Stellen Sie sich vor, wie folgt:

class Vehicle 

class Car : Vehicle 
class CarRed : Car 
class CarBlue : Car 

class Truck : Vehicle 
class TruckRed : Truck 
class TruckBlue : Truck 

Hinweis, dass die Fahrzeuge entweder Autos oder Lastwagen sein. Außerdem können Fahrzeuge entweder rot oder blau sein.Dies funktioniert einwandfrei, aber es gibt ein Problem, wenn Sie eine neue Farbe oder einen neuen Fahrzeugtyp hinzufügen möchten, da die Änderungslast quadratisch zunimmt.

Dieses Problem wird durch das GOF-Entwurfsmusterbuch beschrieben - insbesondere das Brückenmuster.

Obwohl es nicht speziell die Bedenken bezüglich Namespaces behandelt, sagt mein Instinkt, dass die Situationen ähnlich sind. Ich würde sagen, wenn Sie das vermeiden können, dann sollten Sie.

Answer 6

Es ist im Allgemeinen eine gute Idee, Ihre Pakete nicht nach einem bestimmten implementierten Muster zu benennen, sondern eher nach der Geschäfts- oder Funktionsdomäne, zu der sie gehören.

dh:

Org.MyCompany.BusinessObjects.Maintenance.Contacts 
Org.MyCompany.BusinessObjects.Incidents.Contacts 
Org.MyCompany.BusinessObjects.Search.Contacts 

statt:

Org.MyCompany.Contacts 

die Klassen/Schnittstellen/Objekte enthalten würde/was auch immer, die Operationen auf "Kontakte" durchzuführen.

Answer 7

haben auch einen Blick auf diese MSDN-Artikel für Richtlinien für die Benennung von Namespaces

Namen von Namespaces: http://msdn.microsoft.com/en-us/library/ms229026.aspx