Nazwy przestrzeni nazw

  • Artykuł

Uwaga

Ta zawartość jest drukowana przez uprawnienie Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Wydanie to zostało opublikowane w 2008 roku, a książka została w pełni zmieniona w trzecim wydaniu. Niektóre informacje na tej stronie mogą być nieaktualne.

Podobnie jak w przypadku innych wytycznych dotyczących nazewnictwa, celem nazewnictwa przestrzeni nazw jest stworzenie wystarczającej jasności dla programisty przy użyciu platformy, aby natychmiast wiedzieć, jaka zawartość przestrzeni nazw może być. Poniższy szablon określa ogólną regułę nazewnictwa przestrzeni nazw:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

Poniżej znajdują się przykłady:

Fabrikam.Math Litware.Security

✔️ Nazwy przestrzeni nazw prefiksu DO o nazwie firmy uniemożliwiają przestrzeniom nazw innym firmom używanie tej samej nazwy.

✔️ Należy użyć stabilnej, niezależnej od wersji nazwy produktu na drugim poziomie nazwy przestrzeni nazw.

❌ NIE należy używać hierarchii organizacyjnych jako podstawy nazw w hierarchiach przestrzeni nazw, ponieważ nazwy grup w korporacjach wydają się być krótkotrwałe. Organizowanie hierarchii przestrzeni nazw wokół grup powiązanych technologii.

✔️ Do używać PascalCasing i oddzielnych składników przestrzeni nazw z kropkami (np. Microsoft.Office.PowerPoint). Jeśli twoja marka korzysta z nietradycyjnej wielkości liter, należy postępować zgodnie z wielkością liter zdefiniowaną przez markę, nawet jeśli odbiega od normalnej wielkości liter przestrzeni nazw.

✔️ ROZWAŻ użycie nazw w liczbie mnogiej, jeśli jest to konieczne.

Na przykład użyj polecenia System.Collections zamiast System.Collection. Nazwy i akronimy marki są jednak wyjątkami od tej reguły. Na przykład użyj polecenia System.IO zamiast System.IOs.

❌ NIE używaj tej samej nazwy dla przestrzeni nazw i typu w tej przestrzeni nazw.

Na przykład nie używaj Debug jako nazwy przestrzeni nazw, a następnie podaj klasę o nazwie Debug w tej samej przestrzeni nazw. Kilka kompilatorów wymaga, aby takie typy zostały w pełni kwalifikowane.

Przestrzenie nazw i konflikty nazw typów

❌ NIE wprowadzaj nazw typów ogólnych, takich jak Element, Node, Logi Message.

Istnieje bardzo duże prawdopodobieństwo, że spowoduje to konflikty nazw typów w typowych scenariuszach. Należy zakwalifikować nazwy typów ogólnych (FormElement, XmlNode, EventLog, SoapMessage).

Istnieją konkretne wskazówki dotyczące unikania konfliktów nazw typów dla różnych kategorii przestrzeni nazw.

  • Przestrzenie nazw modelu aplikacji

    Przestrzenie nazw należące do pojedynczego modelu aplikacji są bardzo często używane razem, ale prawie nigdy nie są używane z przestrzeniami nazw innych modeli aplikacji. Na przykład System.Windows.Forms przestrzeń nazw jest bardzo rzadko używana razem z przestrzenią System.Web.UI nazw. Poniżej znajduje się lista dobrze znanych grup przestrzeni nazw modelu aplikacji:

    System.Windows* System.Web.UI*

    ❌ Nie należy podawać tej samej nazwy typom w przestrzeniach nazw w ramach pojedynczego modelu aplikacji.

    Na przykład nie należy dodawać typu o nazwie Page do System.Web.UI.Adapters przestrzeni nazw, ponieważ System.Web.UI przestrzeń nazw zawiera już typ o nazwie Page.

  • Przestrzenie nazw infrastruktury

    Ta grupa zawiera przestrzenie nazw, które są rzadko importowane podczas tworzenia typowych aplikacji. Na przykład .Design przestrzenie nazw są używane głównie podczas opracowywania narzędzi programistycznych. Unikanie konfliktów z typami w tych przestrzeniach nazw nie jest krytyczne.

  • Podstawowe przestrzenie nazw

    Podstawowe przestrzenie nazw obejmują wszystkie System przestrzenie nazw, z wyłączeniem przestrzeni nazw modeli aplikacji i przestrzeni nazw infrastruktury. Podstawowe przestrzenie nazw obejmują między innymi , System, System.IO, System.Xmli System.Net.

    ❌ NIE należy nadawać nazw typów, które mogłyby powodować konflikt z dowolnym typem w podstawowych przestrzeniach nazw.

    Na przykład nigdy nie należy używać Stream jako nazwy typu. Spowodowałoby to konflikt z System.IO.Stream, bardzo często używanym typem.

  • Grupy przestrzeni nazw technologii

    Ta kategoria obejmuje wszystkie przestrzenie nazw z tymi samymi dwoma pierwszymi węzłami (<Company>.<Technology>*przestrzeni nazw ), takimi jak Microsoft.Build.Utilities i Microsoft.Build.Tasks. Ważne jest, aby typy należące do jednej technologii nie powodować konfliktu ze sobą.

    ❌ NIE przypisuj nazw typów, które mogłyby powodować konflikt z innymi typami w ramach jednej technologii.

    ❌ NIE wprowadzaj konfliktów nazw typów między typami w przestrzeniach nazw technologii a przestrzenią nazw modelu aplikacji (chyba że technologia nie ma być używana z modelem aplikacji).

© Części 2005, 2009 Microsoft Corporation. Wszelkie prawa zastrzeżone.

Reprinted by permission of Pearson Education, Inc. from Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition by Krzysztof Cwalina and Brad Abrams, published oct 22, 2008 by Addison-Wesley Professional w ramach Microsoft Windows Development Series.

Zobacz też