it-swarm.it

La convenzione Java nome del pacchetto è difettosa?

Conosciamo tutti la convenzione Java nome del pacchetto di invertire il nome del dominio. Ad esempio www.evilcorp.com, per convenzione, avrebbe scelto di avere i loro Java com.evilcorp.stuff.

Sempre più mi stufo di questo. Come programmatore commerciale, incontro ripetutamente che il nome del pacchetto software è completamente irrilevante a causa di un nuovo marchio, acquisizione o simili.

Nel mondo opensource ci sono meno cambi di nome e quindi ha senso. Tuttavia, mi sembra che la durata di conservazione di molti software (commerciali/interni) sia molto più lunga di quella dell'organizzazione che li produce.

Il problema è spesso aggravato dai progetti software che portano il reparto marketing a usare il nome du jour che usano si riferiscono a un determinato progetto. Un nome che cambierà senza dubbio 3 mesi lungo la linea per rendere i nuovi vestiti dell'imperatore freschi e nuovi.

Per questo motivo, ho principalmente smesso di usare il dominio inverso come nome del pacchetto. Certo, se questo viene fatto su larga scala, c'è il rischio di collisioni di nomi, ma sicuramente questo è mitigato dall'uso di nomi di software "univoci", dall'evitare parole generiche o dall'uso del dominio inverso per progetti destinati a essere venduti/rilasciati come librerie .

Altri pensieri?

28
Martin Algesten

Citerò il consiglio che Microsoft fornisce per gli spazi dei nomi (pacchetti .NET), che non ha la convenzione del nome di dominio. Penso che sia un buon consiglio per Java anche, dal momento che non credo che un nome di dominio rappresenti un'identità solida e stabile.

Il formato generale per un nome di spazio dei nomi è il seguente:

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

Per esempio, Microsoft.WindowsMobile.DirectX.

Fare prefisso i nomi degli spazi dei nomi con un nome di società per evitare che spazi di nomi di società diverse abbiano lo stesso nome e prefisso.

Utilizzare un nome di prodotto stabile, indipendente dalla versione al secondo livello di un nome di spazio dei nomi.

Non utilizzare le gerarchie organizzative come base per i nomi nelle gerarchie dello spazio dei nomi, poiché i nomi dei gruppi all'interno delle società tendono ad avere vita breve.

Il nome dello spazio dei nomi è un identificatore longevo e immutabile. Man mano che le organizzazioni si evolvono, le modifiche non dovrebbero rendere obsoleto il nome dello spazio dei nomi.

Se anche il nome della tua azienda è instabile, potresti voler iniziare con il nome del prodotto.

23
Allon Guralnek

Stai cercando la soluzione a un problema diverso, vale a dire come possiamo evitare che il programmatore X e il programmatore Y si calpestino mettendo i file nello stesso pacchetto.

Il "solo inverti il ​​tuo nome di dominio" risolve questo in modo elegante, poiché sei abbastanza sicuro che se X e Y non sono correlati non sceglieranno lo stesso spazio del nome del pacchetto.

15
user1249

La convenzione non è difettosa. Le persone sono imperfette, come hai ben illustrato te stesso.

Mi vengono in mente 2 vantaggi:

  1. Evita la collisione tra sviluppatori indipendenti. Un dominio è unico. Due persone possono nominare due progetti diversi allo stesso modo, ma un dominio ha esattamente un proprietario.
  2. Rende più facile trovare il manutentore. Se erediti una base di codice, che utilizza una libreria open source, è meglio che sia in un pacchetto che ti aiuti a trovarla. Ormai non ha molta importanza, perché sicuramente sarai in grado di cercarlo su Google. Ma 10 anni fa, questo non era così evidente.
10
back2dos

Il nome di dominio inverso è stato utilizzato per evitare collisioni di nomi nel caso in cui organizzazioni diverse utilizzino gli stessi nomi di classe nelle loro librerie. È una soluzione semplice e un po 'di coraggio presenta alcuni inconvenienti (ad esempio che dire delle collisioni di nomi per le classi nella stessa organizzazione?).

Non sei obbligato a usarlo, è una convenzione, non una regola do o die. Ad esempio, alcuni Java non rispettano Convenzioni del codice Java .

Ma considera le alternative. Come vorresti, ad esempio, due nomi di classe pienamente qualificati per un LogFactory:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

o

org.Apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

Quindi, secondo me, usa quello che ti piace purché includa il buon senso e una considerazione per gli utenti della tua biblioteca.

7
user7197

Quando inizio un nuovo progetto, insisto sempre su un nome interno e immutabile che gli addetti al marketing possano o meno conoscere, poiché verrà indicato solo nel codice sorgente. In questo modo, non devo preoccuparmi delle modifiche al nome del progetto e dell'inquinamento dello spazio dei nomi.

Questo scenario è adatto a me, poiché il codice sorgente non è in genere una parte importante del prodotto, vale a dire che i progetti sono generalmente sistemi proprietari a sorgente chiuso. Tuttavia, nei progetti open source in cui il codice sorgente è il prodotto, questo potrebbe non essere fattibile.

4
SWeko