Nomes de namespaces

  • Artigo

Observação

Este conteúdo é reimpresso com permissão da Pearson Education, Inc. de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Essa edição foi publicada em 2008 e, desde então, o livro foi totalmente revisado na terceira edição. Algumas das informações nesta página podem estar desatualizadas.

Assim como acontece com outras diretrizes de nomenclatura, a meta ao nomear namespaces está criando clareza suficiente para o programador usar a estrutura para saber imediatamente qual será o conteúdo do namespace. O modelo a seguir especifica a regra geral para nomear namespaces:

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

Os exemplos são os seguintes:

Fabrikam.Math Litware.Security

✔️ CRIE nomes de namespace de prefixo com um nome de empresa para evitar que namespaces de empresas diferentes tenham o mesmo nome.

✔️ USE um nome de produto estável e independente de versão no segundo nível de um nome de namespace.

❌ NÃO use hierarquias organizacionais como base para nomes em hierarquias de namespace, pois os nomes de grupo dentro das corporações tendem a ser de curta duração. Organize a hierarquia de namespaces em torno de grupos de tecnologias relacionadas.

✔️ USE PascalCasing e separe componentes de namespace com períodos (por exemplo, Microsoft.Office.PowerPoint). Se sua marca emprega maiúsculas e minúsculas não tradicionais, você deve seguir o que foi definido por sua marca, mesmo que isso se desvie do uso normal do namespace.

✔️ CONSIDERE o uso de nomes de namespace no plural, quando apropriado.

Por exemplo, use System.Collections ao invés de System.Collection. No entanto, nomes de marcas e acrônimos são exceções a essa regra. Por exemplo, use System.IO ao invés de System.IOs.

❌ NÃO use o mesmo nome para um namespace e um tipo nesse namespace.

Por exemplo, não use Debug como um nome de namespace e forneça também uma classe nomeada Debug no mesmo namespace. Vários compiladores exigem que esses tipos sejam totalmente qualificados.

Namespaces e conflitos de nome de tipo

❌NÃO introduza nomes de tipo genéricos, como Element, Node, Log e Message.

Há uma probabilidade muito alta de que isso leve a conflitos de nome de tipo em cenários comuns. Você deve qualificar os nomes de tipo genérico (FormElement, XmlNode, EventLog, SoapMessage).

Há diretrizes específicas para evitar conflitos de nome de tipo para diferentes categorias de namespaces.

  • Namespaces do modelo de aplicativo

    Namespaces pertencentes a um único modelo de aplicativo geralmente são usados juntos, mas quase nunca são usados com namespaces de outros modelos de aplicativo. Por exemplo, o namespace System.Windows.Forms raramente é usado junto com o namespace System.Web.UI. Veja a seguir uma lista de grupos de namespace conhecidos do modelo de aplicativo:

    System.Windows* System.Web.UI*

    ❌ NÃO dê o mesmo nome a tipos em namespaces em um único modelo de aplicativo.

    Por exemplo, não adicione um tipo nomeado Page ao namespace System.Web.UI.Adapters, pois o namespace System.Web.UI já contém um tipo chamado Page.

  • Namespaces de infraestrutura

    Esse grupo contém namespaces que raramente são importados durante o desenvolvimento de aplicativos comuns. Por exemplo, namespaces .Design são usados principalmente ao desenvolver ferramentas de programação. Evitar conflitos com tipos nesses namespaces não é crítico.

  • Namespaces principais

    Os namespaces principais incluem todos os namespaces System, namespaces dos modelos de aplicativo e os namespaces de infraestrutura. Os namespaces principais incluem, entre outros, System, System.IOe System.XmlSystem.Net.

    ❌ NÃO forneça nomes de tipos que entrariam em conflito com qualquer tipo nos namespaces principais.

    Por exemplo, nunca use Stream como um nome de tipo. Ele entraria em conflito com o System.IO.Stream, um tipo usado com muita frequência.

  • Grupos de namespaces de tecnologia

    Essa categoria inclui todos os namespaces com os mesmos dois primeiros nós de namespace (<Company>.<Technology>*), como Microsoft.Build.Utilities e Microsoft.Build.Tasks. É importante que os tipos pertencentes a uma única tecnologia não entrem em conflito entre si.

    ❌ NÃO atribua nomes de tipo que entrariam em conflito com outros tipos dentro de uma única tecnologia.

    ❌ NÃO introduza conflitos de nome de tipo entre tipos em namespaces de tecnologia e um namespace de modelo de aplicativo (a menos que a tecnologia não se destine a ser usada com o modelo de aplicativo).

Portions © 2005, 2009 Microsoft Corporation. Todos os direitos reservados.

Reimpresso com permissão da Pearson Education, Inc. das Diretrizes de Design do Framework: convenções, linguagens e padrões para bibliotecas do .NET reutilizável, 2ª edição por Krzysztof Cwalina e Brad Abrams, publicado em 22 de outubro de 2008 por Addison-Wesley Professional como parte da série de desenvolvimento do Microsoft Windows.

Confira também