Nome do pacote semântica mais apropriado do que `util` para as seguintes coisas?

Como um palpite considera o pacote java.util, é um depósito de lixo para várias classes que, na maioria dos casos, não compartilham nada em comum, exceto a pessoa que os colocou lá, com preguiça ou falta de inspiração para criar um nome de pacote mais semanticamente correto para sua classe.

Como apenas um exemplo, considere a classe UUIDqual teria sido um nome de pacote semanticamente correto para essa classe?

Estou trabalhando na implementação de minha própria UUIDclasse para ser mais leve. Não quero usar me.myproject.util.UUIDo nome do meu pacote.

Eu considerei, me.myproject.rfc4122.UUIDmas isso não implica a semântica do uso de UUID.

Também considerei, me.myproject.uuid.UUIDmas não gosto da tautologia, mesmo que seja uma abordagem popular no Python colocar uma classe em um módulo com o mesmo nome e packagesno Java não seja semanticamente equivalente ao modulesdo Python.

Também considerei, me.myproject.UUIDmas rejeitei, porque não quero poluir essa parte do espaço para nome com coisas que não estão relacionadas. Isso apenas eleva o problema a um nível superior.

Eu também considerei, me.myproject.lib.UUIDmas isso não tem mais significado semântico do que .utile apenas renomeia o problema.

semantics: o ramo da linguística e da lógica preocupada com o significado .

O problema de tentar colocar cada classe em um pacote com um nome semanticamente correto para essa classe é que ela tende a levar a pacotes que contêm muito poucas classes ou, às vezes, apenas uma classe. Por sua vez, isso leva a uma infinidade de pacotes.

Uma abordagem mais pragmática da nomeação de pacotes é simplesmente ajudá-lo a encontrar coisas. Manter o material usado com frequência que você sempre sabe onde encontrar todos os agrupados em um só lugar os mantém fora do caminho e, portanto, facilita a localização do material mais raramente usado. Portanto, você realmente não precisa de nomes de pacotes que sejam semanticamente corretos para cada uma das classes que eles contêm; você só precisa de nomes de pacotes que não sejam semanticamente incorretos. Obviamente, o nome do pacote 'util' foi escolhido de acordo com esta linha de pensamento: não é o nome semanticamente correto para as classes que contém, mas também não é semanticamente incorreto, e isso é bom o suficiente.

Portanto, se esse seu tipo de UUID estiver destinado a ser usado apenas por esse aplicativo específico (como evidenciado pelo fato de que você planeja colocá-lo em 'meuprojeto'), provavelmente faz parte do 'modelo' do seu projeto. Você já deve ter um pacote 'model', contendo o conjunto de todas as classes que correspondem às suas entidades persistentes, muitas das quais provavelmente têm relacionamentos entre elas, sendo os UUIDs provavelmente o meio de implementar esses relacionamentos. Além disso, seus UUIDs provavelmente sabem como se manter, certo? E também, seus UUIDs provavelmente só podem ser encontrados como membros de suas entidades modelo, certo? Portanto, seu pacote de modelo é provavelmente o melhor lugar para isso.

Caso contrário, se esse seu tipo de UUID também puder ser usado em outros projetos, ele precisará ser visto como parte de alguma estrutura. Portanto, ele pode estar na pasta de origem raiz dessa estrutura, ou em alguns subconjuntos de 'tipos', como sugerido pelo MainMa, ou mesmo em algum subconjunto dessa estrutura chamado 'util' ou 'misc'. Nada de errado com isso.

O objetivo dos pacotes é agrupar classes de acordo com alguns critérios (pacote por tipo / camada vs. pacote por recurso etc.). Realmente não vejo sentido em criar pacotes para apenas uma classe - especialmente se você não espera que outras classes sejam incluídas no futuro.

Também acho que o nome do pacote "util" não é totalmente sem sentido - apenas agrupa as classes por um critério específico - para mim a classe "util" significa que não faz parte do domínio do aplicativo, mas também não faz parte do framework (não influencia a estrutura do aplicativo). É basicamente apenas uma extensão da biblioteca (não) padrão.

Nesse caso, eu não teria problemas em colocar essa classe UUID no pacote "util". Se houver outras classes de utilitários relacionadas ao UUID (como uma classe separada para gerar UUIDs), é fácil refatorar e criar um pacote "util.uuid" para eles (a menos que você esteja criando uma biblioteca e o UUID fará parte da interface exposta). , você precisa ter um pouco de "visão de futuro").

O tio Bob tem algumas diretrizes sobre a separação de pacotes.

Os três primeiros princípios de pacotes são sobre coesão de pacotes, eles nos dizem o que colocar em pacotes:

1. O grânulo de reutilização é o grânulo de liberação
2. Classes que mudam juntas são empacotadas juntas
3. Classes usadas em conjunto são empacotadas em conjunto

Então, respondendo à sua pergunta, quem / o que usará a classe UUID, a possui como atributo ou invoca operações nela? Como está o seu gráfico de dependência ? O UUID será usado junto com quais outras classes ?

Dependendo da sua resposta, talvez você deve chamá-lo de me.myproject.identity pacote, o me.myproject.serialization pacote, me.myproject. DTO ou mesmo algo completamente diferente. Talvez a classe UUID deva ser mantida junto com seus modelos e você a coloque em um pacote que você já possui, como me.myproject.models .

Primeiro, UUID (com maiúsculas) parece uma péssima idéia para o nome do pacote ou nome da classe para mim, de todos os estilos aplicados de uma maneira ou de outra, todos os nomes em maiúsculas estão associados às "constantes". Os pacotes têm como objetivo organizar as coisas, a maneira mais fácil de nomear um pacote é pelo valor das classes que ele possui:

• você pode optar por separar as classes pelo seu valor comercial, por exemplo com.example.identifier;
• ou por seu valor técnico, por exemplo com.example.uuid.

Mantenha a TI simples