Partilhar via

Nomes de namespaces

  • Artigo

Nota

Este conteúdo é reimpresso com permissão da Pearson Education, Inc., a partir 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 revisto na terceira edição. Algumas das informações nesta página podem estar desatualizadas.

Como acontece com outras diretrizes de nomenclatura, o objetivo ao nomear namespaces é criar clareza suficiente para o programador que usa a estrutura 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>]

Seguem-se alguns exemplos:

Fabrikam.Math Litware.Security

✔️ Nomes de namespace de prefixo DO com um nome de empresa para impedir que namespaces de empresas diferentes tenham o mesmo nome.

✔️ DO 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, porque 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.

✔️ O DO usa PascalCasing e separa componentes de namespace com pontos (por exemplo, Microsoft.Office.PowerPoint). Se sua marca emprega invólucro não tradicional, você deve seguir o invólucro definido por sua marca, mesmo que ele se desvie do invólucro de namespace normal.

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

Por exemplo, use System.Collections em vez de System.Collection. No entanto, nomes de marcas e siglas são exceções a essa regra. Por exemplo, use System.IO em vez 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, em seguida, também forneça 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éricos (FormElement, XmlNode, EventLog, SoapMessage).

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

  • Namespaces de modelo de aplicativo

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

    System.Windows* System.Web.UI*

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

    Por exemplo, não adicione um tipo nomeado Page ao System.Web.UI.Adapters namespace, porque o System.Web.UI namespace 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, .Design namespaces são usados principalmente no desenvolvimento de ferramentas de programação. Evitar conflitos com tipos nesses namespaces não é fundamental.

  • Namespaces principais

    Os namespaces principais incluem todos os System namespaces, excluindo namespaces dos modelos de aplicativo e os namespaces Infrastructure. Os namespaces principais incluem, entre outros, System, , System.IOSystem.Xmle System.Net.

    ❌ NÃO dê nomes de tipos que entrem em conflito com qualquer tipo nos namespaces Core.

    Por exemplo, nunca use Stream como um nome de tipo. Entraria em conflito com System.IO.Streamo , um tipo muito usado.

  • Grupos de namespaces de tecnologia

    Esta categoria inclui todos os namespaces com os mesmos dois primeiros nós de (<Company>.<Technology>*namespace ), 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 entrem 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).

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

Reimpresso com permissão da Pearson Education, Inc., de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition por Krzysztof Cwalina e Brad Abrams, publicado em 22 de outubro de 2008 por Addison-Wesley Professional como parte da Microsoft Windows Development Series.

Consulte também