Usar o mesmo nome para o espaço para nome e a classe dentro dele é problemático.
Se o espaço para nome contiver mais de uma classe, por que outras classes seriam colocadas lá? não parece certo, porque o objetivo do nome do espaço para nome é descrever todas as classes dentro dele, não apenas uma. Por exemplo, se você tem JsonSerialization
, BinarySerialization
e XmlSerialization
classes em um namespace, faria sentido para nomear seu namespace XmlSerialization
?
O que geralmente acontece é que, devido à extração de uma classe de um espaço para nome existente ou a uma mesclagem entre várias classes ou outra reorganização, você se encontra com um espaço para nome que contém uma classe principal ; progressivamente, classes menores são colocadas lá porque estão um pouco relacionadas à classe original. Por exemplo, um espaço para nome LogParser
pode conter uma única classe LogParser
e alguém o coloca LogConverter
, porque é bastante relacionado ao analisador LogSearcher
, etc. O problema aqui é que o nome do espaço para nome não foi alterado: assim que LogConverter
foi adicionado, o O nome deveria ter sido alterado para LogsProcessing
ou, simplesmente Logs
,.
Se o espaço para nome contiver apenas uma classe, pode ser um sinal de um problema na organização do código.
Embora eu tenha visto algumas vezes as situações em que uma única classe com princípios SOLID adequados era muito diferente de qualquer outra coisa na base de código e, portanto, foi colocada em um espaço de nome dedicado, esses casos são raros. Mais frequentemente, isso é indicativo de um problema. Da mesma forma, nada impede que você tenha uma classe contendo um único método, mas, na maioria das vezes, essas classes indicariam um problema.
Mesmo que seu espaço para nome contenha apenas uma classe, geralmente há uma maneira de ser mais específico ao nomear a classe e mais geral ao nomear o espaço para nome. Imagine um aplicativo que, entre outras coisas, deve, em um determinado momento, converter arquivos escritos no formato ABC para o formato DEF. A conversão não requer desserialização / serialização de / para os objetos de negócios e é feita aplicando várias expressões regulares curtas o suficiente para serem colocadas na própria classe de conversão chamadaAbcToDefConverter
. Toda a lógica de conversão leva cerca de 80 LLOC em cerca de dez métodos interdependentes - parece uma situação em que não há absolutamente nenhuma necessidade de dividir a classe existente, nem criar classes adicionais. Como a parte restante do aplicativo não tem nada a ver com conversões, a classe não pode ser agrupada com outras classes nos namespaces existentes. Então, cria-se um espaço para nome chamado AbcToDefConverter
. Embora não haja nada inerentemente errado nisso, também é possível usar um nome mais genérico, como Converters
. Em linguagens como Python, onde nomes mais curtos são preferidos e repetição é aplicada, pode até se tornar converters.Abc_To_Def
.
Portanto, use nomes diferentes para namespaces e para as classes que eles contêm. O nome de uma classe deve indicar o que a classe está fazendo, enquanto o nome do espaço para nome deve destacar o que é comum em todas as classes inseridas nela.
A propósito, as classes de utilidade são erradas por natureza: em vez de conter algo específico, como aritmética de precisão arbitrária, elas contêm tudo o que não foi encontrado em outras classes . Isso é simplesmente uma má nomeação, assim como um Miscellaneous
diretório em uma área de trabalho - algo que é indicativo da falta de organização.
A nomeação existe por um motivo: para facilitar sua vida quando você precisar encontrar coisas mais tarde. Você sabe que, se precisar desenhar um gráfico, tente procurar "gráfico" ou "plot". Quando você precisar alterar a maneira como um aplicativo gera faturas, você pesquisará "fatura [e / ing]" ou "fatura". Da mesma forma, tente imaginar um caso em que você dirá para si mesmo: "hm, esse recurso provavelmente deve ser encontrado em diversos". Eu não posso
Veja o .NET Framework. A maioria dessas classes não é de utilidade? Quero dizer, eles têm poucas coisas a ver com o domínio comercial. Se eu trabalho em um aplicativo financeiro, site de comércio eletrônico ou na plataforma educacional de próxima geração, serializar XML ou ler arquivos ou fazer consultas SQL ou realizar transações é tudo de utilidade. No entanto, eles não são chamados UtilitySerialization
ou UtilityTransaction
e não estão no Utility
espaço para nome. Eles têm nomes próprios, o que torna possível (e fácil, obrigado desenvolvedores do .NET!) Encontrá-los quando eu precisar deles.
O mesmo vale para as aulas que você geralmente reutiliza em seus aplicativos. Eles não são classes de utilidade. São classes que fazem certas coisas, e as coisas que fazem devem realmente ser os nomes das classes.
Imagine que você criou um código que lida com unidades e conversão de unidades. Você pode nomear Utility
e ser odiado por seus colegas; ou você pode nomear Units
e UnitsConversion
.