Convenzioni di denominazione e organizzazione dei pacchetti

Il motivo per cui il nome del dominio inverso è l'inizio del nome di un pacchetto è ridurre la possibilità di conflitti di denominazione. Questo è particolarmente importante se si sta scrivendo una libreria o un framework. Questo spiega perché "com" e "org" sono lì dentro.

Altrimenti, ognuno è diverso e sceglie la struttura del pacchetto in modo diverso. Una ragione per cui l'opzione 1 potrebbe essere migliore è che non ci sia un reale destinction tra le funzionalità o che abbia un sacco di codice che attraversa. Con ciò, l'opzione 2 potrebbe avere più senso se le funzionalità in realtà si escludono a vicenda in qualche modo.

Inoltre, scommetto che l'opzione 1 è generalmente il modo in cui la maggior parte dei progetti inizia, e quindi nessuno lo cambia mai (o se ne preoccupa) dopo. Non sarei sorpreso se molte aziende non riflettessero molto sulla loro struttura dei pacchetti.

Concorda con gli altri sul prefisso del pacchetto che è il dominio della società.

Nel secondo punto, di solito scelgo i nomi dei pacchetti come suggerisci, per caratteristica prima per tipo di file (come hai scritto, l'altra politica è spesso scelta).

Nota che il codice tecnico (come StringHelper o MenuInterceptor) non è direttamente una funzione, quindi non segue le stesse convenzioni.

Lo preferisco perché:

• quando si lavora su una funzione, si trova facilmente il codice corrispondente
• puoi utilizzare la visibilità di package (intermedia tra una classe interna privata e una classe veramente pubblica).
• puoi avviare test automatici per verificare completamente una funzionalità (è ciò che conta per il tuo cliente, ed è anche ciò che potrebbe rompersi quando modifichi il vecchio codice)
• se un progetto ha in genere piccole funzionalità con poche classi, o molte classi opzionali che non sono sempre necessarie, le sottodirectory potrebbero non essere necessarie, tutte le classi possono essere contenute nello stesso pacchetto (e lasciare che il suffisso indichi quale ruolo gioca quella classe nella funzione).

A proposito, penso che molte funzionalità in genere non condividano molto codice. Se un codice è riutilizzabile, può essere:

• in un livello diverso (come il codice tecnico), quindi completamente altrove (forse non nello stesso progetto Java)
• in una superclasse (il codice comune può usare pacchetti come le funzioni)

Da quello che ho visto, il primo è comune in Java e nei suoi parenti (ActionScript, ad esempio). Non ne conosco la ragione, ma presumo che sia qualcosa a che fare con l'evitare qualsiasi possibile scontro di denominazione.

C # e .NET in generale, così come credo che Python, preferiscono il secondo stile. In effetti, le linee guida .NET scoraggiano espressamente lo stile Java e raccomandano: CompanyName.ApplicationName.ModuleName.LogicalGroup per esempio Cyberdyne.Skynet.SelfDefense.CyborgActivation

Bene, il primo è per pura convenzione. Nella specifica Java, si consiglia di denominare i pacchetti come il contrario del nome di dominio della propria azienda poiché ciò garantirebbe l'univocità. Questa è la ragione per cui i pacchetti Java sono chiamati così. C ++ e C #, e quindi .NET, seguono la convenzione namespace che esiste da anni. Non credo che nessuno di questi modi sia intrinsecamente migliore di qualsiasi altro modo, cioè il modo in cui le lingue si sono evolute.