Todos conhecemos a convenção de nome de pacote Java de mudar o nome de domínio. Ou seja www.evilcorp.com, por convenção, optou por ter seus pacotes java com.evilcorp.stuff.
Cada vez mais estou farto disso. Como programador comercial, encontro repetidamente que o nome do pacote de software é completamente irrelevante devido a algumas alterações de marca, aquisição ou similar.
No mundo de código aberto, há menos mudanças de nome; portanto, faz sentido. No entanto, parece-me que o prazo de validade de muitas partes do software (comercial / interno) é muito maior do que o da organização que as cria.
O problema geralmente é agravado pelos projetos de software que assumem a liderança do departamento de marketing para usar o nome do dia em que se referem a um determinado projeto. Um nome que, sem falhar, mudará três meses abaixo da linha para fazer com que as novas roupas do imperador pareçam novas e frescas.
Por causa disso, parei de usar o domínio reverso como nome do pacote. É verdade que, se isso for feito em larga escala, há risco de colisões de nomes, mas certamente isso é atenuado pelo uso de nomes de software "únicos", evitando palavras genéricas ou usando o domínio reverso para projetos destinados a serem vendidos / liberados como bibliotecas .
Outros pensamentos?
We're all familiar with the Java package name convention of turning the domain name around.- um..no nós não somos ... :)com.java.etc.etc. Apache (no site Apache.org) nomeia seus pacotesorg.apache.etc.etc. Você vê o padrão.Respostas:
Vou citar o conselho que a Microsoft dá para namespaces (pacotes do .NET), que não tem a convenção de nome de domínio. Eu acho que é um bom conselho para pacotes Java também, já que não acredito que um nome de domínio represente uma identidade sólida e estável.
Se mesmo o nome da sua empresa é instável, você pode começar apenas com o nome do produto.
fonte
Você está procurando a solução para um problema diferente, ou seja, como evitamos que o programador X e o programador Y pisem nos dedos uns dos outros, colocando os arquivos no mesmo pacote.
O "apenas inverta seu nome de domínio" resolve isso de uma maneira elegante, pois você tem certeza de que, se X e Y não estiverem relacionados, eles não escolherão o mesmo espaço de nome de pacote.
fonte
A convenção não é falha. As pessoas são falhas, como você se ilustrou bem.
Eu posso pensar em 2 benefícios:
fonte
O nome de domínio reverso foi usado para evitar colisões de nomes, caso organizações diferentes usem os mesmos nomes de classe em suas bibliotecas. É uma solução simples e o off cource tem algumas desvantagens (por exemplo, o que dizer de colisões de nomes para classes na mesma organização?).
Você não é obrigado a usá-lo, é uma convenção e não uma regra de fazer ou morrer. Por exemplo, alguns programadores Java não respeitam as convenções de código Java .
Mas considere as alternativas. Como você, por exemplo, gostaria de dois nomes de classe totalmente qualificados para um LogFactory:
ou
Portanto, em meus pensamentos, use o que quiser, desde que inclua bom senso e consideração pelos usuários da sua biblioteca.
fonte
Quando inicio um novo projeto, sempre insisto em um nome interno e imutável que o pessoal de marketing possa ou não saber, pois ele será mencionado apenas no código-fonte. Dessa forma, não preciso me preocupar com alterações no nome do projeto e poluição do espaço para nome.
Esse cenário me encaixa, porque o código fonte geralmente não é uma parte importante do produto, ou seja, os projetos geralmente são sistemas proprietários de código fechado. No entanto, em projetos de código aberto em que o código-fonte é o produto, isso pode não ser viável.
fonte