Nome del pacchetto semanticamente più appropriato di "util" per le seguenti cose?

Il problema con il tentativo di mettere ogni classe in un pacchetto che ha un nome semanticamente corretto per quella classe è che tende a portare a pacchetti che contengono pochissime classi, o qualche volta anche solo una classe. Questo a sua volta porta a una moltitudine di pacchetti.

Un approccio più pragmatico alla denominazione dei pacchetti è semplicemente quello di aiutarti a trovare le cose. Mantenere le cose di uso frequente che sai sempre dove trovare raggruppate in un unico posto le tiene fuori mano e quindi rende più facile trovare le cose più raramente usate. Quindi, non hai davvero bisogno di nomi di pacchetti che siano semanticamente corretti per ognuna delle classi che contengono, hai solo bisogno di nomi di pacchetti che non sono semanticamente scorretti. Ovviamente, il nome del pacchetto 'util' è stato scelto in base a questa linea di pensiero: non è il nome semanticamente corretto per le classi che contiene, ma non è semanticamente corretto, e questo è abbastanza buono.

Quindi, se questo tuo tipo UUID è destinato a essere usato solo da questa specifica applicazione, (come evidenziato dal fatto che stai pianificando di inserirlo in 'myproject'), allora probabilmente è parte del 'modello del tuo progetto. Dovresti già avere un pacchetto 'modello', contenente l'insieme di tutte le classi che corrispondono alle tue entità persistenti, molte delle quali probabilmente hanno relazioni tra loro, con gli UUID che probabilmente sono il mezzo per implementare queste relazioni. Inoltre, i tuoi UUID probabilmente sanno come persistere, giusto? Inoltre, probabilmente i tuoi UUID possono essere trovati solo come membri delle entità del tuo modello, giusto? Quindi, il tuo pacchetto modello è probabilmente il posto migliore per questo.

Altrimenti, se questo tuo tipo UUID può essere usato anche in altri progetti, allora deve essere visto come parte di qualche framework. Quindi, potrebbe vivere nella cartella radice di quel framework, o in un sottoprogetto di tipo 'types' come suggerito da MainMa, o anche in qualche sotto-pacchetto di quel framework chiamato 'util' o 'misc'. Niente di male in questo.

Scopo dei pacchetti è raggruppare le classi in base ad alcuni criteri (pacchetto per tipo / livello rispetto a pacchetto per caratteristica ecc.). Non vedo davvero il punto di creare pacchetti per una sola classe, specialmente se non prevedi che in futuro ci saranno altre classi in questo pacchetto.

Inoltre, penso che il nome del pacchetto "util" non sia del tutto privo di significato: raggruppa semplicemente le classi secondo uno specifico criterio - per me la classe "util" significa che non fa parte del dominio dell'applicazione, ma non è nemmeno un parte del framework (non influenza la struttura dell'applicazione). È fondamentalmente solo un'estensione della libreria (non) standard.

In questo caso non avrei problemi a inserire questa classe UUID nel pacchetto "util". Se ci saranno altre classi di utility relative all'UUID (come una classe separata per generare UUID), è facile da refactoring e creare il pacchetto "util.uuid" per loro (a meno che tu non stia creando una libreria e UUID faccia parte dell'interfaccia esposta) , quindi devi essere un po '"lungimirante").

Uncle Bob ha alcune linee guida sulla separazione dei pacchetti.

I primi tre principi del pacchetto riguardano la coesione dei pacchetti, ci dicono cosa mettere all'interno dei pacchetti:

1. Il granello di riutilizzo è il granello della versione
2. Le classi che cambiano insieme sono raggruppate insieme
3. Le classi utilizzate insieme sono raggruppate insieme

Quindi, rispondendo alla tua domanda, chi / cosa sta per utilizzare la classe UUID, avere come attributo o richiamare le operazioni in esso? Qual è il tuo grafico delle dipendenze ? UUID verrà utilizzato insieme a quali altre classi ?

A seconda della risposta, forse dovresti chiamarlo il pacchetto me.myproject.identity , il pacchetto me.myproject.serialization , me.myproject. DTO o anche qualcos'altro interamente. Forse la classe UUID dovrebbe essere tenuta insieme ai tuoi modelli e tu la inserirai in un pacchetto che hai già, come me.myproject.models .

Prima di tutto, UUID (con maiuscole) mi sembra una pessima idea per il nome del pacchetto o il nome della classe, da tutti gli stili applicati in un modo o nell'altro tutti i nomi maiuscoli sono associati alle "costanti". I pacchetti hanno lo scopo di organizzare le cose, il modo più semplice per nominare un pacchetto è il valore delle classi che contiene:

• puoi scegliere di separare le classi in base al loro valore di bussines, ad esempio com.example.identifier ;
• o in base al loro valore tecnico, ad esempio com.example.uuid .

Mantieni l'IT semplice