La convenzione del nome del pacchetto Java è difettosa? [chiuso]

Conosciamo tutti la convenzione del nome del pacchetto Java di invertire il nome di dominio. Cioè www.evilcorp.com, per convenzione, avrebbero scelto di avere i loro pacchetti 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, 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 da progetti software che portano il reparto marketing a usare il nome del giorno che usano per riferirsi a un determinato progetto. Un nome che, senza fallo, cambierà 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", evitando parole generiche o usando il dominio inverso per progetti destinati a essere venduti / rilasciati come librerie .

Altri pensieri?

Citerò il consiglio che Microsoft fornisce per gli spazi dei nomi (pacchetti .NET), che non ha la convenzione dei nomi di dominio. Penso che sia un buon consiglio anche per i pacchetti Java, poiché 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>]

Ad 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. Con l'evoluzione delle organizzazioni, 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.

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 invertire 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.

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 importanza, perché sicuramente sarai in grado di cercarlo su Google. Ma 10 anni fa, questo non era così evidente.

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 es. Per quanto riguarda le 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 programmatori Java non rispettano le 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.

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, ovvero i progetti sono di solito sistemi proprietari a sorgente chiuso. Tuttavia, nei progetti open source in cui il codice sorgente è il prodotto, questo potrebbe non essere fattibile.