Dela via


Namn på namnområden

Kommentar

Det här innehållet skrivs om med behörighet från Pearson Education, Inc. från Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Den utgåvan publicerades 2008, och boken har sedan dess reviderats helt i den tredje utgåvan. En del av informationen på den här sidan kan vara inaktuell.

Precis som med andra namngivningsriktlinjer skapar målet när namnområden namnges tillräcklig klarhet för programmeraren som använder ramverket för att omedelbart veta vad innehållet i namnområdet sannolikt kommer att bli. Följande mall anger den allmänna regeln för namngivning av namnområden:

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

Följande är exempel:

Fabrikam.Math Litware.Security

✔️ GÖR namnområdesnamn med ett företagsnamn för att förhindra att namnområden från olika företag har samma namn.

✔️ Använd ett stabilt, versionsoberoende produktnamn på den andra nivån i ett namnområdesnamn.

❌ Använd INTE organisationshierarkier som grund för namn i namnområdeshierarkier, eftersom gruppnamn inom företag tenderar att vara kortvariga. Organisera hierarkin för namnområden runt grupper med relaterade tekniker.

✔️ ANVÄND PascalCasing och avgränsa namnområdeskomponenter med punkter (t.ex. Microsoft.Office.PowerPoint). Om ditt varumärke använder icke-traditionella höljen bör du följa höljet som definieras av ditt varumärke, även om det avviker från det normala namnområdeshöljet.

✔️ ÖVERVÄG att använda namnområdesnamn i plural där det är lämpligt.

Använd till exempel System.Collections i stället för System.Collection. Varumärkesnamn och förkortningar är dock undantag från den här regeln. Använd till exempel System.IO i stället för System.IOs.

❌ Använd INTE samma namn för ett namnområde och en typ i namnområdet.

Använd till exempel inte Debug som namnområdesnamn och ange sedan även en klass med namnet Debug i samma namnområde. Flera kompilatorer kräver att sådana typer är fullständigt kvalificerade.

Namnområden och typnamnskonflikter

❌ Introducera INTE generiska typnamn som Element, Node, Logoch Message.

Sannolikheten är mycket hög att detta leder till typnamnskonflikter i vanliga scenarier. Du bör kvalificera de allmänna typnamnen (FormElement, XmlNode, EventLog, SoapMessage).

Det finns specifika riktlinjer för att undvika typnamnskonflikter för olika kategorier av namnområden.

  • Namnområden för programmodell

    Namnområden som tillhör en enda programmodell används ofta tillsammans, men de används nästan aldrig med namnområden för andra programmodeller. Namnområdet används till exempel System.Windows.Forms mycket sällan tillsammans med System.Web.UI namnområdet. Följande är en lista över välkända namnområdesgrupper för programmodell:

    System.Windows* System.Web.UI*

    ❌ Ge INTE samma namn till typer i namnområden i en enda programmodell.

    Lägg till exempel inte till en typ med namnet Page i System.Web.UI.Adapters namnområdet, eftersom System.Web.UI namnområdet redan innehåller en typ med namnet Page.

  • Infrastrukturnamnområden

    Den här gruppen innehåller namnområden som sällan importeras under utvecklingen av vanliga program. Namnområden används till exempel .Design främst vid utveckling av programmeringsverktyg. Det är inte viktigt att undvika konflikter med typer i dessa namnområden.

  • Kärnnamnområden

    Kärnnamnområden omfattar alla System namnområden, exklusive namnområden för programmodellerna och infrastrukturnamnrymderna. Kärnnamnområden omfattar bland annat System, System.IO, System.Xmloch System.Net.

    ❌ Ge INTE typer namn som skulle vara i konflikt med någon typ i Core-namnrymderna.

    Använd till exempel aldrig Stream som ett typnamn. Det skulle vara i konflikt med System.IO.Stream, en mycket vanlig typ.

  • Tekniknamnområdesgrupper

    Den här kategorin innehåller alla namnområden med samma två första namnområdesnoder (<Company>.<Technology>*), till exempel Microsoft.Build.Utilities och Microsoft.Build.Tasks. Det är viktigt att typer som hör till en enda teknik inte står i konflikt med varandra.

    ❌ Tilldela INTE typnamn som skulle vara i konflikt med andra typer inom en enda teknik.

    ❌ Introducera INTE typnamnskonflikter mellan typer i tekniknamnområden och ett namnområde för programmodell (såvida inte tekniken inte är avsedd att användas med programmodellen).

Portioner © 2005, 2009 Microsoft Corporation. Med ensamrätt.

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, publicerad 22 okt 2008 av Addison-Wesley Professional som en del av Microsoft Windows Development Series.

Se även