Quale strategia utilizzi per la denominazione dei pacchetti nei progetti Java e perché? [chiuso]

Ci ho pensato tempo fa e recentemente è riemerso mentre il mio negozio sta realizzando la sua prima vera app web Java.

Come intro, vedo due principali strategie di denominazione dei pacchetti. (Per essere chiari, non mi riferisco all'intera parte 'domain.company.project' di questo, sto parlando della convenzione del pacchetto sottostante.) Ad ogni modo, le convenzioni di denominazione dei pacchetti che vedo sono le seguenti:

1. Funzionale: denominazione dei pacchetti in base alla loro funzione architettonicamente piuttosto che alla loro identità in base al dominio aziendale. Un altro termine per questo potrebbe essere la denominazione in base a "livello". Quindi, avresti un pacchetto * .ui e un pacchetto * .domain e un pacchetto * .orm. I tuoi pacchetti sono fette orizzontali anziché verticali.

   Questo è molto più comune della denominazione logica. In effetti, non credo di aver mai visto o sentito parlare di un progetto che fa questo. Questo ovviamente mi rende diffidente (un po 'come pensare di aver trovato una soluzione a un problema NP) poiché non sono molto intelligente e presumo che tutti debbano avere ottime ragioni per farlo nel modo in cui lo fanno. D'altra parte, non sono contrario al fatto che le persone perdano solo l'elefante nella stanza e non ho mai sentito un argomento reale per nominare i pacchetti in questo modo. Sembra solo essere lo standard de facto.

2. Logico: denominare i pacchetti in base alla loro identità di dominio aziendale e inserire in quel pacchetto ogni classe che ha a che fare con quella fetta verticale di funzionalità.

   Non l'ho mai visto o sentito, come ho detto prima, ma per me ha molto senso.

   1. Tendo ad avvicinarmi ai sistemi verticalmente piuttosto che orizzontalmente. Voglio entrare e sviluppare il sistema di elaborazione degli ordini, non il livello di accesso ai dati. Ovviamente, ci sono buone probabilità che tocchi il livello di accesso ai dati nello sviluppo di quel sistema, ma il punto è che non la penso in questo modo. Ciò significa, ovviamente, che quando ricevo un ordine di modifica o voglio implementare qualche nuova funzionalità, sarebbe bello non dover andare in giro in un mucchio di pacchetti per trovare tutte le classi correlate. Invece, guardo solo nel pacchetto X perché quello che sto facendo ha a che fare con X.

   2. Dal punto di vista dello sviluppo, vedo come una grande vittoria avere i tuoi pacchetti documentare il tuo dominio aziendale piuttosto che la tua architettura. Sento che il dominio è quasi sempre la parte del sistema che è più difficile da capire mentre l'architettura del sistema, specialmente a questo punto, sta diventando quasi banale nella sua implementazione. Il fatto che io possa arrivare a un sistema con questo tipo di convenzione di denominazione e immediatamente dalla denominazione dei pacchetti sapere che si tratta di ordini, clienti, imprese, prodotti, ecc. Sembra davvero utile.

   3. Sembra che questo ti consenta di sfruttare molto meglio i modificatori di accesso di Java. Ciò consente di definire in modo molto più pulito le interfacce nei sottosistemi piuttosto che nei livelli del sistema. Quindi, se hai un sottosistema di ordini che desideri sia persistente in modo trasparente, in teoria potresti non far sapere a nient'altro che è persistente non dovendo creare interfacce pubbliche per le sue classi di persistenza nel livello dao e invece impacchettando la classe dao in solo con le classi di cui si occupa. Ovviamente, se volessi esporre questa funzionalità, potresti fornire un'interfaccia per essa o renderla pubblica. Sembra che tu perda molto di questo avendo una fetta verticale delle funzionalità del tuo sistema suddivisa su più pacchetti.

   4. Suppongo che uno svantaggio che posso vedere è che rende un po 'più difficile strappare gli strati. Invece di eliminare o rinominare un pacchetto e poi rilasciarne uno nuovo con una tecnologia alternativa, devi entrare e cambiare tutte le classi in tutti i pacchetti. Tuttavia, non vedo che questo sia un grosso problema. Potrebbe essere dovuto a una mancanza di esperienza, ma devo immaginare che il numero di volte in cui sostituisci le tecnologie impallidisce rispetto al numero di volte in cui entri e modifichi sezioni di funzionalità verticali all'interno del tuo sistema.

Quindi immagino che la domanda ti verrebbe posta, come si nominano i pacchetti e perché? Per favore, capisci che non penso necessariamente di essere incappato nell'oca d'oro o qualcosa del genere qui. Sono abbastanza nuovo in tutto questo con un'esperienza prevalentemente accademica. Tuttavia, non riesco a individuare i buchi nel mio ragionamento, quindi spero che lo possiate tutti così che io possa andare avanti.

Per la progettazione del pacchetto, divido prima per livello, quindi per altre funzionalità.

Ci sono alcune regole aggiuntive:

1. i livelli sono impilati dal più generale (in basso) al più specifico (in alto)
2. ogni livello ha un'interfaccia pubblica (astrazione)
3. uno strato può dipendere solo dall'interfaccia pubblica di un altro strato (incapsulamento)
4. un livello può dipendere solo da livelli più generali (dipendenze dall'alto verso il basso)
5. uno strato dipende preferibilmente dallo strato direttamente sotto di esso

Quindi, per un'applicazione web, ad esempio, potresti avere i seguenti livelli nel tuo livello di applicazione (dall'alto verso il basso):

• livello di presentazione: genera l'interfaccia utente che verrà mostrata nel livello client
• livello applicazione: contiene la logica specifica di un'applicazione, stateful
• livello di servizio: raggruppa le funzionalità per dominio, apolidi
• livello di integrazione: fornisce l'accesso al livello di backend (db, jms, email, ...)

Per il layout del pacchetto risultante, queste sono alcune regole aggiuntive:

• la radice di ogni nome di pacchetto è <prefix.company>.<appname>.<layer>
• l'interfaccia di un livello è ulteriormente suddivisa per funzionalità: <root>.<logic>
• l'implementazione privata di un livello ha il prefisso privato: <root>.private

Ecco un esempio di layout.

Il livello di presentazione è diviso per tecnologia di visualizzazione e, facoltativamente, per (gruppi di) applicazioni.

com.company.appname.presentation.internal
com.company.appname.presentation.springmvc.product
com.company.appname.presentation.servlet
...

Il livello dell'applicazione è suddiviso in casi d'uso.

com.company.appname.application.lookupproduct
com.company.appname.application.internal.lookupproduct
com.company.appname.application.editclient
com.company.appname.application.internal.editclient
...

Il livello di servizio è suddiviso in domini aziendali, influenzati dalla logica del dominio in un livello di backend.

com.company.appname.service.clientservice
com.company.appname.service.internal.jmsclientservice
com.company.appname.service.internal.xmlclientservice
com.company.appname.service.productservice
...

Il livello di integrazione è suddiviso in "tecnologie" e oggetti di accesso.

com.company.appname.integration.jmsgateway
com.company.appname.integration.internal.mqjmsgateway
com.company.appname.integration.productdao
com.company.appname.integration.internal.dbproductdao
com.company.appname.integration.internal.mockproductdao
...

I vantaggi di separare pacchetti come questo sono che è più facile gestire la complessità e aumenta la testabilità e la riusabilità. Anche se sembra un sacco di spese generali, nella mia esperienza in realtà è molto naturale e tutti coloro che lavorano su questa struttura (o simile) lo prendono in pochi giorni.

Perché penso che l'approccio verticale non sia così buono?

Nel modello a strati, diversi moduli di alto livello possono utilizzare lo stesso modulo di livello inferiore. Ad esempio: è possibile creare più viste per la stessa applicazione, più applicazioni possono utilizzare lo stesso servizio, più servizi possono utilizzare lo stesso gateway. Il trucco qui è che quando ci si sposta attraverso i livelli, il livello di funzionalità cambia. I moduli nei livelli più specifici non mappano 1-1 sui moduli del livello più generale, perché i livelli di funzionalità che esprimono non mappano 1-1.

Quando si utilizza l'approccio verticale per la progettazione del pacchetto, ovvero si divide prima per funzionalità, quindi si forza tutti i blocchi con diversi livelli di funzionalità nella stessa "giacca di funzionalità". Potresti progettare i tuoi moduli generali per quello più specifico. Ma ciò viola l'importante principio secondo cui il livello più generale non dovrebbe conoscere i livelli più specifici. Il livello di servizio, ad esempio, non dovrebbe essere modellato sui concetti del livello dell'applicazione.

Mi ritrovo ad attenermi ai principi di progettazione della confezione dello zio Bob . In breve, le classi che devono essere riutilizzate insieme e modificate insieme (per lo stesso motivo, ad esempio un cambiamento di dipendenza o un cambiamento di framework) dovrebbero essere messe nello stesso pacchetto. Secondo me, la scomposizione funzionale avrebbe maggiori possibilità di raggiungere questi obiettivi rispetto alla scomposizione verticale / specifica del business nella maggior parte delle applicazioni.

Ad esempio, una porzione orizzontale di oggetti di dominio può essere riutilizzata da diversi tipi di front-end o persino applicazioni ed è probabile che una porzione orizzontale del front-end web cambi insieme quando è necessario modificare il framework web sottostante. D'altra parte, è facile immaginare l'effetto a catena di queste modifiche su molti pacchetti se le classi in diverse aree funzionali sono raggruppate in quei pacchetti.

Ovviamente, non tutti i tipi di software sono uguali e la ripartizione verticale può avere senso (in termini di raggiungimento degli obiettivi di riusabilità e chiudibilità al cambiamento) in alcuni progetti.

Di solito sono presenti entrambi i livelli di divisione. Dall'alto ci sono le unità di schieramento. Questi sono denominati "logicamente" (nei tuoi termini, pensa alle funzionalità di Eclipse). All'interno dell'unità di distribuzione, hai una divisione funzionale dei pacchetti (pensa ai plugin Eclipse).

Ad esempio, è funzione com.feature, ed è composto com.feature.client, com.feature.coree com.feature.uiplugin. All'interno dei plugin, ho pochissima divisione con altri pacchetti, anche se non è insolito.

Aggiornamento: A proposito, Juergen Hoeller parla molto dell'organizzazione del codice su InfoQ: http://www.infoq.com/presentations/code-organization-large-projects . Juergen è uno degli architetti della primavera e sa molto di queste cose.

La maggior parte dei progetti java su cui ho lavorato per suddividere i pacchetti java prima funzionalmente, poi logicamente.

Di solito le parti sono sufficientemente grandi da essere suddivise in artefatti di build separati, dove potresti mettere le funzionalità di base in un jar, le API in un altro, le cose del frontend web in un warfile, ecc.

I pacchetti devono essere compilati e distribuiti come un'unità. Quando si considera quali classi appartengono a un pacchetto, uno dei criteri chiave sono le sue dipendenze. Da quali altri pacchetti (incluse le librerie di terze parti) dipende questa classe. Un sistema ben organizzato raggrupperà le classi con dipendenze simili in un pacchetto. Ciò limita l'impatto di una modifica in una libreria, poiché solo pochi pacchetti ben definiti dipenderanno da essa.

Sembra che il tuo sistema logico e verticale possa tendere a "macchiare" le dipendenze nella maggior parte dei pacchetti. Cioè, se ogni funzionalità è confezionata come una sezione verticale, ogni pacchetto dipenderà da ogni libreria di terze parti che usi. È probabile che qualsiasi modifica a una libreria si propaghi all'intero sistema.

Personalmente preferisco raggruppare le classi in modo logico, quindi all'interno che includa un sottopacchetto per ogni partecipazione funzionale.

Obiettivi del confezionamento

Dopotutto, i pacchetti riguardano il raggruppamento delle cose: l'idea di classi correlate vivono l'una vicino all'altra. Se vivono nello stesso pacchetto possono sfruttare il pacchetto privato per limitare la visibilità. Il problema è raggruppare tutta la tua vista e le tue cose in un unico pacchetto può portare a confondere molte classi in un unico pacchetto. La prossima cosa sensata da fare è quindi creare di conseguenza la visualizzazione, la persistenza, i sotto-pacchetti util e le classi di refactoring. Sfortunatamente, l'ambito protetto e privato del pacchetto non supporta il concetto di pacchetto e sottopacchetto corrente poiché ciò aiuterebbe a far rispettare tali regole di visibilità.

Ora vedo il valore nella separazione tramite funzionalità perché quale valore c'è per raggruppare tutte le cose relative alla vista. Le cose in questa strategia di denominazione si disconnettono con alcune classi nella vista mentre altre sono persistenti e così via.

Un esempio della mia struttura logica del packaging

A scopo illustrativo, nominiamo due moduli: non useremo il nome modulo come concetto che raggruppa le classi sotto un particolare ramo di un albero del pacchetto.

Vantaggi

Un client che utilizza Banana.store.BananaStore è esposto solo alle funzionalità che desideriamo rendere disponibili. La versione di ibernazione è un dettaglio di implementazione di cui non hanno bisogno di essere a conoscenza né dovrebbero vedere queste classi mentre aggiungono disordine alle operazioni di archiviazione.

Altri vantaggi logici e funzionali

Più si sale verso la radice, più ampio diventa lo scopo e le cose che appartengono a un pacchetto iniziano a mostrare sempre più dipendenze da cose che appartengono ai suoi moduli. Se si esaminasse ad esempio il modulo "banana", la maggior parte delle dipendenze sarebbe limitata all'interno di quel modulo. In effetti, la maggior parte degli helper sotto "banana" non sarebbe affatto referenziata al di fuori di questo scopo del pacchetto.

Perché funzionalità?

Quale valore si ottiene raggruppando le cose in base alla funzionalità. La maggior parte delle classi in questo caso sono indipendenti l'una dall'altra con poca o nessuna necessità di trarre vantaggio dai metodi o dalle classi private del pacchetto. Il loro refactoring in modo da inserirli nei propri sottopacchetti guadagna poco, ma aiuta a ridurre il disordine.

Modifiche dello sviluppatore al sistema

Quando gli sviluppatori hanno il compito di apportare modifiche un po 'più che banali, sembra sciocco che potenzialmente abbiano modifiche che includono file da tutte le aree dell'albero dei pacchetti. Con l'approccio strutturato logico le loro modifiche sono più locali all'interno della stessa parte dell'albero dei pacchetti che sembra giusto.

Entrambi gli approcci funzionali (architettonici) e logici (caratteristici) al packaging hanno un posto. Molte applicazioni di esempio (quelle che si trovano nei libri di testo, ecc.) Seguono l'approccio funzionale di inserire presentazioni, servizi aziendali, mappatura dei dati e altri livelli architettonici in pacchetti separati. Nelle applicazioni di esempio, ogni pacchetto spesso ha solo poche o solo una classe.

Questo approccio iniziale va bene poiché un esempio artificioso spesso serve a: 1) mappare concettualmente l'architettura del framework presentato, 2) è fatto con un unico scopo logico (ad esempio aggiungere / rimuovere / aggiornare / eliminare animali domestici da una clinica) . Il problema è che molti lettori lo considerano uno standard che non ha limiti.

Man mano che un'applicazione "aziendale" si espande per includere sempre più funzionalità, seguire l' approccio funzionale diventa un peso. Sebbene io sappia dove cercare i tipi in base al livello dell'architettura (ad esempio i web controller sotto un pacchetto "web" o "ui", ecc.), Lo sviluppo di una singola caratteristica logica inizia a richiedere il salto avanti e indietro tra molti pacchetti. Questo è ingombrante, per lo meno, ma è peggio di così.

Poiché i tipi logicamente correlati non sono impacchettati insieme, l'API è eccessivamente pubblicizzata; l'interazione tra tipi correlati logicamente è forzata a essere "pubblica" in modo che i tipi possano importare e interagire tra loro (la capacità di ridurre al minimo la visibilità del pacchetto / predefinita è persa).

Se sto costruendo una libreria di framework, i miei pacchetti seguiranno sicuramente un approccio di packaging funzionale / architettonico. I consumatori di API potrebbero persino apprezzare che le loro istruzioni di importazione contengono un pacchetto intuitivo che prende il nome dall'architettura.

Al contrario, quando creo un'applicazione aziendale, creerò un pacchetto per funzionalità. Non ho problemi a posizionare Widget, WidgetService e WidgetController tutti nello stesso pacchetto " com.myorg.widget. " E quindi a sfruttare la visibilità predefinita (e avere meno istruzioni di importazione e dipendenze tra pacchetti).

Esistono, tuttavia, casi di cross-over. Se il mio WidgetService viene utilizzato da molti domini logici (funzionalità), potrei creare un pacchetto " com.myorg.common.service. ". C'è anche una buona possibilità che crei classi con l'intenzione di essere riutilizzabili tra le funzionalità e finire con pacchetti come " com.myorg.common.ui.helpers. " E " com.myorg.common.util. ". Potrei anche finire per spostare tutte queste classi "comuni" successive in un progetto separato e includerle nella mia applicazione aziendale come dipendenza myorg-commons.jar.

Dipende dalla granularità dei tuoi processi logici?

Se sono autonomi, spesso hai un nuovo progetto per loro nel controllo del codice sorgente, piuttosto che un nuovo pacchetto.

Il progetto a cui sto lavorando al momento sta errando verso la divisione logica, c'è un pacchetto per l'aspetto jython, un pacchetto per un motore di regole, pacchetti per foo, bar, binglewozzle, ecc. Sto cercando di avere i parser specifici per XML / writer per ogni modulo all'interno di quel pacchetto, piuttosto che avere un pacchetto XML (cosa che ho fatto in precedenza), sebbene ci sarà ancora un pacchetto XML di base in cui va la logica condivisa. Una ragione di ciò, tuttavia, è che può essere estensibile (plug-in) e quindi ogni plug-in dovrà definire anche il proprio codice XML (o database, ecc.), Quindi la centralizzazione potrebbe introdurre problemi in seguito.

Alla fine sembra essere come sembra più sensato per il particolare progetto. Tuttavia, penso che sia facile impacchettare seguendo le linee del tipico diagramma a strati del progetto. Ti ritroverai con un mix di packaging logico e funzionale.

Quello che serve sono gli spazi dei nomi con tag. Un parser XML per alcune funzionalità Jython potrebbe essere etichettato sia Jython che XML, invece di dover scegliere uno o l'altro.

O forse sto ondeggiando.

Cerco di progettare le strutture dei pacchetti in modo tale che se dovessi disegnare un grafico delle dipendenze, sarebbe facile da seguire e utilizzare un modello coerente, con il minor numero di riferimenti circolari possibile.

Per me, questo è molto più facile da mantenere e visualizzare in un sistema di denominazione verticale piuttosto che orizzontale. se component1.display ha un riferimento a component2.dataaccess, questo genera più campanelli di avvertimento che se display.component1 ha un riferimento a dataaccess. component2.

Ovviamente, i componenti condivisi da entrambi vanno nel loro pacchetto.

Seguo e propongo totalmente l'organizzazione logica ("per caratteristica")! Un pacchetto dovrebbe seguire il concetto di "modulo" il più fedelmente possibile. L'organizzazione funzionale può distribuire un modulo su un progetto, con conseguente minore incapsulamento e incline a modifiche nei dettagli di implementazione.

Prendiamo ad esempio un plugin Eclipse: mettere tutte le visualizzazioni o le azioni in un unico pacchetto sarebbe un casino. Invece, ogni componente di una funzionalità dovrebbe andare nel pacchetto della funzionalità, o se ce ne sono molti, in sottopacchetti (featureA.handlers, featureA.preferences ecc.)

Naturalmente, il problema risiede nel sistema di pacchetti gerarchici (che tra gli altri possiede Java), che rende impossibile o almeno molto difficile la gestione delle questioni ortogonali, sebbene si verifichino ovunque!

Personalmente sceglierei la denominazione funzionale. Il motivo breve: evita la duplicazione del codice o l'incubo delle dipendenze.

Lasciami elaborare un po '. Cosa succede quando si utilizza un file jar esterno, con il proprio albero dei pacchetti? Stai effettivamente importando il codice (compilato) nel tuo progetto, e con esso un albero dei pacchetti (funzionalmente separato). Avrebbe senso usare le due convenzioni di denominazione contemporaneamente? No, a meno che non ti sia stato nascosto. E lo è, se il tuo progetto è abbastanza piccolo e ha un singolo componente. Ma se hai più unità logiche, probabilmente non vuoi reimplementare, diciamo, il modulo di caricamento dei file di dati. Vuoi condividerlo tra unità logiche, non avere dipendenze artificiali tra unità logicamente non correlate e non devi scegliere in quale unità mettere quel particolare strumento condiviso.

Immagino che questo sia il motivo per cui la denominazione funzionale è la più utilizzata nei progetti che raggiungono, o sono destinati a raggiungere, una certa dimensione e la denominazione logica viene utilizzata nelle convenzioni di denominazione delle classi per tenere traccia del ruolo specifico, se uno qualsiasi di ciascuna classe in un pacchetto.

Cercherò di rispondere in modo più preciso a ciascuno dei tuoi punti sulla denominazione logica.

1. Se devi andare a pescare nelle vecchie classi per modificare le funzionalità quando hai un cambio di programma, è segno di cattiva astrazione: dovresti costruire classi che forniscano una funzionalità ben definita, definibile in una breve frase. Solo poche classi di alto livello dovrebbero riunire tutto ciò per riflettere la tua business intelligence. In questo modo, sarai in grado di riutilizzare più codice, avere una manutenzione più semplice, una documentazione più chiara e meno problemi di dipendenza.

2. Dipende principalmente dal modo in cui crei il tuo progetto. Sicuramente, la vista logica e funzionale sono ortogonali. Quindi, se si utilizza una convenzione di denominazione, è necessario applicare l'altra ai nomi di classe per mantenere un certo ordine, o passare da una convenzione di denominazione a un'altra a una certa profondità.

3. I modificatori di accesso sono un buon modo per consentire ad altre classi che comprendono la tua elaborazione di accedere alle parti interne della tua classe. Relazione logica non significa comprensione dei vincoli algoritmici o di concorrenza. Funzionale può, anche se non lo fa. Sono molto stanco di modificatori di accesso diversi da quelli pubblici e privati, perché spesso nascondono una mancanza di un'architettura adeguata e un'astrazione di classe.

4. Nei grandi progetti commerciali, il cambiamento delle tecnologie avviene più spesso di quanto si potrebbe credere. Ad esempio, ho dovuto cambiare già 3 volte il parser XML, 2 volte la tecnologia di caching e 2 volte il software di geolocalizzazione. Meno male che avevo nascosto tutti i dettagli grintosi in un pacchetto dedicato ...

È un esperimento interessante non usare affatto i pacchetti (eccetto il pacchetto root).

La domanda che sorge quindi è: quando e perché ha senso introdurre i pacchetti. Presumibilmente, la risposta sarà diversa da quella a cui avresti risposto all'inizio del progetto.

Presumo che la tua domanda sorga affatto, perché i pacchetti sono come le categorie ea volte è difficile decidere per l'uno o l'altro. A volte i tag sarebbero più apprezzati per comunicare che una classe è utilizzabile in molti contesti.

Da un punto di vista puramente pratico, i costrutti di visibilità di java consentono alle classi nello stesso pacchetto di accedere a metodi e proprietà con visibilità protectede default, oltre a publicquelli. Usare metodi non pubblici da un livello completamente diverso del codice sarebbe sicuramente un grande odore di codice. Quindi tendo a mettere le classi dello stesso livello nello stesso pacchetto.

Non uso spesso questi metodi protetti o predefiniti altrove, tranne forse negli unit test per la classe, ma quando lo faccio, proviene sempre da una classe allo stesso livello

Dipende. Nella mia linea di lavoro, a volte dividiamo i pacchetti per funzioni (accesso ai dati, analisi) o per classe di attività (credito, azioni, tassi di interesse). Seleziona la struttura più conveniente per la tua squadra.

Dalla mia esperienza, la riutilizzabilità crea più problemi che soluzioni. Con i processori e la memoria più recenti ed economici, preferirei la duplicazione del codice piuttosto che una stretta integrazione per il riutilizzo.