Se pacchetto per feature, ma ho molte classi omogenee, quale è preferibile?

Question

Se pacchetto per feature, ma ho molte classi omogenee, quale è preferibile?

#1 da (3 voti)

1

Mi chiedo se questo è il modo corretto di gestire la mia situazione quando si impacchettano per feature. Utilizzare la seguente struttura di progetto come esempio:

com.foobar.web.Bootstrap.java
com.foobar.web.TcpServer.java
com.foobar.web.RequestHandler.java

Ogni parte della funzione web si trova nel pacchetto web - buona finora. Poiché tutte le classi di pagine sono omogenee e usano lo stesso genitore, è una cattiva pratica metterle in un nuovo sottoprogetto per layer / type per evitare pacchetti apparentemente vuoti? In effetti:

com.foobar.web.pages.AbstractPage.java
com.foobar.web.pages.HomePage.java
com.foobar.web.pages.BuyPage.java
com.foobar.web.pages.SupportPage.java

Sembra quasi che io stia confezionando per feature e poi sub-packaging per strato. Trovo questo difficile da evitare a meno che non metta ogni singola pagina nel proprio pacchetto solitario (ad esempio .home.HomePage.java , ecc.) Che si sente inutile in quanto sono da soli senza classi aggiuntive nei loro pacchetti.

Che cosa è preferibile, ognuno nel proprio pacchetto .home.HomePage (solo pacchetto per caratteristica) o tutti omogenei in un unico pacchetto plurale .pages.HomePage (pacchetto per funzionalità, quindi digitare combinato)?

object-oriented naming packages

posta Thomas Ryder 20.06.2017 - 02:02

fonte

1 risposta

Leggi altre domande sui tag object-oriented naming packages

È standard per registrare ogni caso di un'istruzione switch? Gli oggetti di servizio sono necessari in OOP?

score 3 · Answer 1

Come qualcuno che ha sofferto per anni in un sistema di pacchetti per livello, apprezzo ciò che stai cercando di fare. Tuttavia, stai cercando di attenersi fedelmente al tuo principio organizzativo, anche se ti costringe a fare scelte sciocche.

Piuttosto che una devozione fanatica al tuo principio organizzativo permettimi di incoraggiarti a seguire una preoccupazione:

Semplifica la ricerca di cose.

Il motivo principale per raggruppare le cose per caratteristica è che quando creo o aggiorno una funzione, posso trovare i file che mi interessano tutti nello stesso posto. Non tutti i file si raggruppano bene attorno a una singola funzione. Non disperdere questi file al vento aspettandosi che vivano vite tristi e solitarie nel loro stesso pacchetto. Trova qualche buon modo per organizzarli. Se questo sembra un livello, allora va bene.

Pensa che un ibrido sarebbe di gran lunga troppo confuso? Considera questo esempio:

hackernoon.com: pacchetto per caratteristiche e non strati

Voglio dire per gridare ad alta voce in realtà ha un pacchetto di caratteristiche CHIAMATE! Quindi quali sono gli altri? No, questi pacchetti non sono tutte funzioni. Va bene. Mi dà un chiaro indizio quando scivola da un tipo di principio organizzativo a un altro. Mi sento come se potessi trovare le cose bene e prevedere dove metterei cose nuove. Questo è tutto ciò di cui ho bisogno.