Namen von Namespaces
Der für einen Namespace gewählte Name sollte die Funktionalität angeben, die von den Typen im Namespace verfügbar gemacht wird. Beispielsweise enthält der System.Net.Sockets-Namespace Typen, die Entwicklern die Verwendung von Sockets für die netzwerkübergreifende Kommunikation ermöglichen.
Das allgemeine Format für einen Namespacenamen lautet wie folgt:
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
Beispielsweise Microsoft.WindowsMobile.DirectX.
Stellen Sie Namespacenamen einen Firmennamen als Präfix voran, um zu verhindern, dass Namespaces unterschiedlicher Firmen denselben Namen und dasselbe Präfix aufweisen.
Verwenden Sie auf der zweiten Ebene eines Namespacenamens einen dauerhaften, versionsunabhängigen Produktnamen.
Verwenden Sie Organisationshierarchien als Grundlage für Namen in Namespacehierarchien, weil Gruppennamen in Unternehmen häufig kurzlebig sind.
Der Namespacename ist ein langlebiger und unveränderlicher Bezeichner. Während der Entwicklung von Organisationen sollten Änderungen nicht dazu führen, dass der Namespacename veraltet ist.
Verwenden Sie die Pascal-Schreibweise, und trennen Sie Namespacekomponenten durch einen Punkt (z. B. Microsoft.Office.PowerPoint). Wenn Sie für Ihre Marke eine andere als die traditionelle Schreibweise verwenden, halten Sie die für Ihre Marke festgelegte Schreibweise ein, auch wenn diese von der normalen Schreibweise für Namespaces abweicht.
Verwenden Sie für Namespacenamen ggf. den Plural. Verwenden Sie z. B. System.Collections anstelle von System.Collection. Markennamen und Akronyme sind jedoch Ausnahmen zu dieser Regel. Verwenden Sie z. B. System.IO anstelle von System.IOs.
Verwenden Sie nicht denselben Namen für einen Namespace und einen Typ in diesem Namespace. Verwenden Sie z. B. nicht Debug als Namespacename, während Sie gleichzeitig in demselben Namespace eine Klasse mit dem Namen Debug bereitstellen. Mehrere Compiler erfordern, dass solche Typen vollqualifiziert sind.
Konflikte zwischen Namespace- und Typnamen
Wenn Sie einen Namespace- oder Typnamen wählen, der einen Konflikt mit einem vorhandenen Namen verursacht, müssen Bibliotheksbenutzer Verweise auf die betroffenen Elemente qualifizieren. Dies sollte in den meisten Entwicklungsszenarien nicht der Fall sein.
Einige der Richtlinien, die in diesem Abschnitt vorgestellt werden, sind für die folgenden Kategorien von Namespaces relevant:
Anwendungsmodellnamespaces
Infrastrukturnamespaces
Kernnamespaces
Technologienamespacegruppen
Die Namespaces in einem Anwendungsmodell stellen den für eine Klasse von Anwendungen spezifischen Satz von Funktionalität bereit. Beispielsweise stellen die Typen in den System.Windows.Forms-Namespaces die Funktionalität bereit, die zum Schreiben von Windows Forms-Clientanwendungen erforderlich ist. Die Typen in den System.Web-Namespaces unterstützen das Schreiben webbasierter Serveranwendungen. Im Allgemeinen werden Namespaces aus unterschiedlichen Anwendungsmodellen nicht in derselben Anwendung verwendet. Daher ist die Wahrscheinlichkeit gering, dass Namenskonflikte die Entwickler betreffen, die Ihre Bibliothek verwenden.
Infrastrukturanwendungen stellen spezielle Unterstützung bereit, und auf sie wird in Programmcode selten verwiesen. Beispielsweise werden die Typen in *.Designer-Namespaces von Programmentwicklungstools verwendet. Die *.Permissions-Namespaces sind ein weiteres Beispiel für Infrastrukturnamespaces. Die Wahrscheinlichkeit ist gering, dass Namenskonflikte mit Typen in Infrastrukturnamespaces von den Entwicklern berücksichtigt werden müssen, die Ihre Bibliothek verwenden.
Die Kernnamespaces sind die System.*-Namespaces (außer den Anwendungs- und Infrastrukturnamespaces). Beispiele für Kernnamespaces sind System und System.Text. Vermeiden Sie unbedingt Namenskonflikte mit Typen in den Kernnnamespaces.
Die Namespaces für eine bestimmte Technologie verfügen über dieselben Bezeichner der ersten und zweiten Ebene (Company.technology.*). Vermeiden Sie Namenskonflikte innerhalb einer Technologie.
Allgemeine Richtlinien für Namespaces
Führen Sie keine generischen Typnamen, z. B. Element, Node, Log und Message, ein. In allgemeinen Szenarien führt dies mit sehr hoher Wahrscheinlichkeit zu Konflikten mit Typnamen. Qualifizieren Sie generische Typnamen (FormElement, XmlNode, EventLog, SoapMessage).
Richtlinien für Anwendungsnamespaces
Legen Sie nicht für Typen in Namespaces in einem einzigen Anwendungsmodell den gleichen Namen fest.
Wenn Sie z. B. eine Bibliothek spezieller Steuerelemente schreiben, die von Windows Forms-Anwendungsentwicklern verwendet werden sollen, führen Sie keinen Typ mit dem Namen Checkbox ein, weil ein Typ mit diesem Namen bereits für das Anwendungsmodell vorhanden ist (CheckBox).
Richtlinien für Kernnamespaces
Legen Sie für Typen keine Namen fest, die zu einem Konflikt mit einem Typ in den Kernnamespaces führen.
Verwenden Sie z. B. nicht Directory als Typname, da dies zu einem Konflikt mit dem Directory-Typ führt.
Richtlinien für Technologienamespaces
Weisen Sie keine Typnamen zu, die in einer einzelnen Technologie zu einem Konflikt mit anderen Typen führen.
Führen Sie keine Typnamenskonflikte zwischen Typen in Technologienamespaces und einem Anwendungsmodellnamespace ein (es sei denn, die Technologie ist nicht für die Verwendung in dem Anwendungsmodell vorgesehen).
Copyright für einzelne Teile 2005 Microsoft Corporation. Alle Rechte vorbehalten.
Copyright für einzelne Teile Addison-Wesley Corporation. Alle Rechte vorbehalten.
Weitere Informationen zu Entwurfsrichtlinien finden Sie unter „Framework-Entwurfs-Richtlinien: Idiome, Konventionen und Muster für wiederverwendbare .NET-Bibliotheken von Krzysztof Cwalina“ book und Brad Abrams, veröffentlicht von Addison-Wesley, 2005.