A convenção de nome do pacote Java é falha? [fechadas]

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?

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.

O formato geral para um nome de espaço para nome é o seguinte:

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

Por exemplo Microsoft.WindowsMobile.DirectX,.

Prefixe nomes de namespace com um nome de empresa para impedir que namespaces de empresas diferentes tenham o mesmo nome e prefixo.

Use um nome de produto estável e independente de versão no segundo nível de um nome de espaço para nome.

Não use hierarquias organizacionais como base para nomes nas hierarquias de namespace, porque os nomes de grupos nas empresas tendem a ter vida curta.

O nome do espaço para nome é um identificador de longa duração e imutável. À medida que as organizações evoluem, as alterações não devem tornar o nome do espaço para nome obsoleto.

Se mesmo o nome da sua empresa é instável, você pode começar apenas com o nome do produto.

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.

A convenção não é falha. As pessoas são falhas, como você se ilustrou bem.

Eu posso pensar em 2 benefícios:

1. Evita colisão entre desenvolvedores independentes. Um domínio é único. Duas pessoas podem nomear dois projetos diferentes da mesma forma, mas um domínio tem exatamente um proprietário.
2. Facilita a localização do mantenedor. Se você herdar uma base de código, que usa alguma biblioteca de código aberto, é melhor que esteja em um pacote que o ajude a encontrá-la. Até agora, isso realmente não importa, porque você certamente poderá fazer uma busca no Google. Mas 10 anos atrás, isso não era tão evidente.

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:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

ou

org.apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

Portanto, em meus pensamentos, use o que quiser, desde que inclua bom senso e consideração pelos usuários da sua biblioteca.

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.