c ++ uso namespace e regras de nomeação

Question

No projeto que estamos tentando chegar a um acordo sobre o uso namespace. Nós decidimos que o primeiro nível será "productName" eo segundo é "moduleName".

productName::moduleName

Agora, se o módulo é uma espécie de módulo do utilitário não há nenhum problema para adicionar terceiro namespace. Por exemplo, para adicionar "str":. ProductName :: utilityModuleName :: str - ao espaço divisão onde todas as "cordas" coisas relacionadas irá

Se o módulo é o principal módulo de negócios que temos muitas oportunidades e quase nenhum acordo.

Por exemplo

class productName::mainModuleName::DomainObject

e

class productName::mainModuleName::DomainObjectSomethingElseViewForExample

pode ser tanto em

namespace productName::mainModuleName::domainObject
class Data
class ViewForExample

Por que devemos criar classes não privados internos e não namespaces? Por que devemos criar classe onde todos os métodos são estáticos (exceto casos em que esta classe vai ser parâmetro de modelo)?

Projeto consistem de 1Gb de código-fonte. Então, qual é a melhor prática para módulos dividem em namespaces no c ++?

Answer 1

O que namespaces são para:

Namespaces são destinadas a estabelecer contexto somente assim você não tem confilcts de nomeação.

Regras gerais:

Especificando demais contexto não é necessário e vai causar mais transtornos do que vale a pena.

Assim que você quer usar seu melhor julgamento, mas ainda siga estas 2 regras:

• Não seja demasiado geral ao usar namespaces
• Não seja demasiado específica ao usar namespaces

Eu não seria tão rigoroso sobre como usar nomes de nomes, e simplesmente usar namespaces com base em um grupo relacionado de código.

Por namespaces que são demasiado gerais não são úteis:

O problema com a divisão do espaço de nomes começando com o nome do produto, é que muitas vezes você vai ter um componente de código, ou alguma biblioteca de base que é comum a vários produtos.

Você também não vai estar usando namespaces Produto2 dentro Product1, tão explicitamente especificando é inútil. Se você estava incluindo arquivos de Produto2 dentro Product1, então é esta conversão nomeação ainda útil?

Por namespaces que são muito específicas não são úteis:

Quando você tem namespaces que são muito específicas, a linha entre esses namespaces distintas começam a se confundir. Você começar a usar os namespaces dentro de si e para trás. Neste momento é melhor generalizar o código comum juntos sob o mesmo namespace.

Classes com tudo estática vs modelos:

"Por que deveríamos criar não interna aulas particulares e não namespaces? Por que devemos criar classes onde todos métodos são estáticos "

Algumas diferenças:

• Os espaços de nomes pode ser implícita usando a using palavra-chave
• Namespaces podem ser alias, as classes são tipos e pode ser typedef'ed
• Os espaços de nomes podem ser adicionados a; você pode adicionar funcionalidade a ele a qualquer momento e adicionar-lhe diretamente
• As classes podem não ser adicionados a sem fazer uma nova classe derivada
• Namespaces podem ter declarações para a frente
• Com aulas você pode ter membros privados e membros protegidos
• As aulas podem ser usados ??com modelos

Exatamente como dividir:

"Projeto consistem de 1Gb de fonte código. Então, qual é a melhor prática para módulos dividem sobre namespaces no c ++? "

É muito subjetivo para dizer exatamente como dividir seu código sem o código fonte exata. Dividindo com base nos módulos embora sons lógico, apenas não o todo produto.

Answer 2

Isso tudo é subjetivo, mas eu hesitaria em ir mais de 3 níveis de profundidade. Ela só fica pesado demais em algum ponto. Assim a menos que sua base de código é muito, muito grande, gostaria de mantê-lo muito rasa.

Vamos dividir o nosso código em subsistemas, e tem um espaço de nomes para cada subsistema. coisas de utilidade iria entrar em seu próprio namespace se de fato eles são reutilizáveis ??em todos os subsistemas.

Answer 3

Parece-me que você está tentando usar namespaces como uma ferramenta de design. Eles não se destinam a isso, eles são destinados a evitar conflitos de nome. Se você não tem os confrontos, você não precisa de espaços de nomes.

Answer 4

Eu divido namespaces dependendo seus usos:

Eu tenho um namespace separado, onde eu ter definido todos os meus interfaces (aulas virtuais puras).

Eu tenho um namespace separado, onde eu ter definido as minhas aulas de biblioteca (como db biblioteca, processamento de biblioteca).

E eu tenho um namespace separado, onde eu tenho o meu core business (lógica de negócio) objetos (como PURCHASE_ORDER, etc).

Eu acho que, a cerca de defini-la de uma forma, que não se torna difícil de lidar no futuro. Assim, você pode verificar as dificuldades que cercam em seu projeto atual.

E se você acha que eles estão bem, você deve ir com ele.