Struttura del pacchetto per un progetto Java?

116

Qual è la procedura migliore per impostare le strutture dei pacchetti in un'applicazione Web Java?

Come configureresti il tuo src, il codice di unit test, ecc.?

java packages

— mawaldne
fonte

95

Potresti seguire il layout standard del progetto di Maven . Non è necessario utilizzare effettivamente Maven, ma renderebbe la transizione più facile in futuro (se necessario). Inoltre, altri sviluppatori saranno abituati a vedere quel layout, poiché molti progetti open source sono disposti in questo modo,

— johnstok
fonte

2

Consiglio anche di utilizzare il layout di Maven se hai una scelta. È una struttura ben congegnata che è stata testata in battaglia ed è familiare a molti sviluppatori.

— Dov Wasserman

15

Puoi utilizzare questo oneliner per creare il layout della directory: mkdir -p src / {main / {java, resources, filters, assembly, config, webapp}, test / {java, resources, filters}, site}

— Daniel Hepper,

1

Il layout standard del progetto di Maven è brutto ...: /

— Yousha Aleayoub

2

@YoushaAleayoub non devi sposarlo

— Ashvin Sharma

59

Ci sono alcune risorse esistenti che potresti controllare:

Per quello che vale, le mie linee guida personali che tendo a usare sono le seguenti:

Inizia con il dominio inverso, ad esempio "com.mycompany".
Usa il nome del prodotto, ad esempio "mioprodotto". In alcuni casi tendo ad avere pacchetti comuni che non appartengono a un particolare prodotto. Questi verrebbero classificati in base alla funzionalità di queste classi comuni, ad esempio "io", "util", "ui", ecc.
Dopo questo diventa più libero. Di solito raggruppo in base al progetto, all'area di funzionalità, alla distribuzione, ecc. Ad esempio, potrei avere "progetto1", "progetto2", "ui", "client", ecc.

Un paio di altri punti:

È abbastanza comune nei progetti su cui ho lavorato che i nomi dei pacchetti fluiscano dalla documentazione di progettazione. Di solito i prodotti sono già suddivisi in aree di funzionalità o scopo.
Non preoccuparti troppo di spingere subito le funzionalità comuni in pacchetti più alti. Attendi che sia necessario tra progetti, prodotti, ecc., Quindi esegui il refactoring.
Guarda le dipendenze tra pacchetti. Non sono tutte cattive, ma può significare uno stretto accoppiamento tra quelle che potrebbero essere unità separate. Ci sono strumenti che possono aiutarti a tenerne traccia.

— lycono
fonte

2

Nel caso del dominio inverso ("com.mycompany"), il pacchetto "com" è solitamente vuoto ad eccezione del sottopacchetto "mycompany"?

— Alex Parker

45

Suggerirei di creare la struttura del pacchetto per funzionalità e non per livello di implementazione. Un buon articolo su questo è le pratiche Java: pacchetto per funzionalità, non livello

— analista dati
fonte

2

Grazie. Questo è quello che stavo cercando per trasmettere i miei pensieri al team

— Pranalee

8

E se desideri cambiare database? Devi solo cercare in 30 pacchetti diversi. Passare da SFTP a servizi web? Ancora una volta devi solo cercare in 30 posti diversi. Sicuramente non un fan.

— SamuelKDavis

1

un altro esempio in cui il confezionamento per livello ha dei vantaggi: se serializzi le classi in JSON (ad es. con gson), se quelle classi sono offuscate (ad es. da Proguard) (de) la serializzazione fallirà; è necessario configurare Proguard per non toccare tali classi - è il più semplice specificare un singolo pacchetto con tutte loro

— jmuet

6

Di solito mi piace avere quanto segue:

bin (binari)
doc (documenti)
inf (Informazioni)
lib (Librerie)
res (risorse)
src (fonte)
tst (test)

Questi possono essere considerati non convenzionali, ma trovo che sia un modo molto carino per organizzare le cose.

"Questi possono essere considerati non convenzionali" In realtà sono non convenzionali e cattivi tra l'altro ...

— mahieddine

2

@mahieddine Perché li consideri cattivi?

— Thomas Johannesmeyer

Non sono stato io a dichiararlo, ma ecco alcuni dei miei pensieri: le tue classi di test sono codice sorgente quindi la directory "tst" (la maggior parte delle persone non abbrevia test btw) dovrebbe essere una sottodirectory di src (ad esempio " src "diventa" src / main "e" tst "diventa" src / test "). Anche "inf" sembra includere contenuto che potrebbe essere in "doc".

— Nico Wawrzyniak

6

The way I usually organise is
- src
        - main
                - java
                - groovy
                - resources
        - test
                - java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc

— Raj
fonte

3

Il modo in cui di solito ho la mia gerarchia di cartelle-

Nome del progetto
- src
- bidone
- test
- libs
- docs

— pdeva
fonte

1

Un altro modo è separare le API, i servizi e le entità in pacchetti diversi.

— Deepak Patankar
fonte