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

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

The general format for a namespace name is as follows:

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

For example, Microsoft.WindowsMobile.DirectX.

Do prefix namespace names with a company name to prevent namespaces from different companies from having the same name and prefix.

Do use a stable, version-independent product name at the second level of a namespace name.

Do not use organizational hierarchies as the basis for names in namespace hierarchies, because group names within corporations tend to be short-lived.

The namespace name is a long-lived and unchanging identifier. As organizations evolve, changes should not make the namespace name obsolete.

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

Stai cercando la soluzione a un problema diverso, ovvero come evitare che il programmatore X e il programmatore Y passino l'uno sull'altro mettendo i file nello stesso pacchetto.

Il "solo invertire il tuo nome di dominio" risolve questo in modo elegante, poiché sei certo che se X e Y non sono collegati, non sceglieranno lo stesso spazio dei nomi del pacchetto.

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

Posso pensare a 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 si eredita un codice base, che utilizza una libreria open source, è meglio trovarsi in un pacchetto che aiuti a trovarlo. Ormai non importa, perché sicuramente sarai in grado di farlo su Google. Ma 10 anni fa, questo non era così evidente.

Il nome di dominio inverso è stato utilizzato per evitare conflitti di nome nel caso in cui diverse organizzazioni usassero gli stessi nomi di classe nelle loro librerie. È una soluzione semplice e off cource ha alcuni inconvenienti (ad esempio, che ne è il nome delle collisioni per le classi nella stessa organizzazione?).

Non sei obbligato a usarlo, è una convenzione, non una regola "fai o muori". Ad esempio, alcuni programmatori Java non rispettano le Convenzioni sui codici Java .

Ma considera le alternative. Ad esempio, come ad esempio due nomi di classe completi per una LogFactory:

a50e8400_e29b_41d4_a716_446655440000.LogFactory
f47ac10b_58cc_4372_a567_0e02b2c3d479.Logfactory

o

org.apache.commons.logging.LogFactory
com.evilcorp.logging.LogFactory

Quindi, nei miei pensieri, usa quello che vuoi purché includa il buon senso e una considerazione per gli utenti della tua biblioteca.

Quando avvio un nuovo progetto, insisto sempre su un nome interno e immutabile che le persone di marketing possano conoscere o meno, in quanto verrà indicato solo nel codice sorgente. In questo modo, non devo preoccuparmi delle modifiche al nome del progetto e dell'inquinamento dei nomi.

Questo scenario è adatto a me, perché il codice sorgente di solito non è una parte importante del prodotto, ad esempio i progetti sono solitamente sistemi proprietari chiusi. Tuttavia, nei progetti open source in cui il codice sorgente è il prodotto, questo potrebbe non essere fattibile.