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

Come un pagliaccio considera il pacchetto java.util, è una discarica per varie classi che nella maggior parte dei casi non condividono nulla in comune tranne la persona che li ha messi lì era pigro o non ispirato a trovare un nome di pacchetto più semanticamente corretto per la loro classe.

Come solo un esempio, prendi la classe UUIDquale sarebbe stato un nome di pacchetto semanticamente corretto per quella classe?

Sto lavorando per implementare la mia UUIDclasse per essere più leggero. Non voglio usare me.myproject.util.UUIDper il mio nome del pacchetto.

Ho considerato, me.myproject.rfc4122.UUIDma ciò non implica la semantica dell'uso di UUID.

Ho anche considerato, me.myproject.uuid.UUIDma non mi piace la tautologia in questo, anche se è un approccio popolare in Python mettere una classe in un modulo con lo stesso nome, e packagesin Java non sono semanticamente equivalenti a modulesin Python.

Ho anche considerato me.myproject.UUIDma rifiutato perché non voglio inquinare quella parte dello spazio dei nomi con cose che non sono correlate. Questo fa semplicemente salire di livello il problema.

Ho anche considerato, me.myproject.lib.UUIDma questo non ha più significato semantico di .utile semplicemente rinomina il problema.

semantics: il ramo della linguistica e della logica interessato al significato .

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 talvolta 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 cose. Mantenere le cose usate di frequente che sai sempre dove trovare tutte raggruppate in un unico posto le tiene lontane dalla strada e quindi rende più facile trovare le cose usate più raramente. Quindi, non hai davvero bisogno di nomi di pacchetti che siano semanticamente corretti per ciascuna delle classi che contengono, hai solo bisogno di nomi di pacchetti che non siano semanticamente errati. 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 è anche semanticamente errato, ed è abbastanza buono.

Quindi, se questo tuo tipo di UUID è destinato ad essere utilizzato solo da questa specifica applicazione (come evidenziato dal fatto che stai pianificando di metterlo sotto 'myproject'), allora probabilmente fa 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à modello, giusto? Quindi, il tuo pacchetto modello è probabilmente il posto migliore per questo.

Altrimenti, se questo tuo tipo UUID può essere utilizzato anche in altri progetti, allora deve essere visto come parte di un framework. Quindi, potrebbe risiedere nella cartella dei sorgenti di root di quel framework, o in alcuni sotto-pacchetti 'types' come suggerito da MainMa, o persino in alcuni sotto-pacchetti di quel framework chiamati 'util' o 'misc'. Niente di sbagliato in questo.

Lo scopo dei pacchetti è di raggruppare le classi in base ad alcuni criteri (pacchetto per tipo / livello vs. pacchetto per caratteristica ecc.). Non vedo davvero il punto di creare un pacchetto per una sola classe - specialmente se non ti aspetti che ci saranno altre classi in questo pacchetto in futuro.

Inoltre penso che il nome del pacchetto "util" non sia del tutto privo di significato - raggruppa solo le classi in base a criteri specifici - per me la classe "util" significa che non fa parte del dominio dell'applicazione, ma non fa 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 utilità correlate a UUID (come classe separata per la generazione di UUID), è facile eseguire il refactoring e creare il pacchetto "util.uuid" per loro (a meno che non si stia creando una libreria e UUID farà parte dell'interfaccia esposta , quindi devi essere un po '"lungimirante").

Lo zio Bob ha alcune linee guida sulla separazione dei pacchetti.

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

1. Il granello di riutilizzo è il granello di rilascio
2. Le classi che cambiano insieme vengono impacchettate insieme
3. Le classi che vengono utilizzate insieme vengono impacchettate insieme

Quindi, rispondendo alla tua domanda, chi / che cosa utilizzerà la classe UUID, la avrà come attributo o invocherà operazioni in essa? Com'è il tuo grafico delle dipendenze ? UUID verrà utilizzato insieme a quali altre classi ?

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

Prima di tutto, UUID (con lettere 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 in maiuscolo sono associati alle "costanti". I pacchetti hanno lo scopo di organizzare cose, il modo più semplice per nominare un pacchetto è in base al valore delle classi che contiene:

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

Mantieni l'IT semplice