Denominazione libreria package-by-feature package-by-layer VS?

Question

So che questo ha diversi post associati, ma ho alcune domande specifiche che spero di poter ottenere aiuto. Scusate se sono molto semplici ..

Ecco un esempio di problema - molto semplificato, ma si ottiene l'immagine - Ho diversi oggetti, che hanno alcune funzioni comuni ad es. reparti di un'azienda farmaceutica: neurologia, oncologia, infezione, ecc. Tutti devono analizzare i file dei documenti dei pazienti e caricare i dati nel database. Naturalmente la natura dei dati è leggermente diversa per ogni dipartimento. Se Ho usato package-by-feature, avrei

com.company.neurology 
     Neurology.java 
     NeurologyDocument.java 
     NeurologyDAO.java 

com.company.infection 
     Infection.java 
     InfectionDocument.java 
     InfectionDAO.java 

ecc Il problema è che devo una classe astratta che le classi documento devono estendersi esempio

AbstractDocument.java 
public class AbstractDocument 
{ 
     public void validateDocument(){...} 
     public void readDocumentHeader(){...} 
     public void readDocumentFooter(){...} 
     ... 
} 

Alcuni file di accesso ai dati, ad es.

DBConnection.java 
    public class DBConnection 
    { 
     public void makeConnectionToDB() {... } 
     public void createCache() {... } 
     public void closeConnectionToDB() {... } 
    } 

alcune classi di errore

ParseError.java, PatientNotFoundException etc. 

Se i pacchetti sono di funzione, da dove vengono queste classi comuni/interfacce andare?

Answer 1

Suggerirei di mantenere le cose semplici. A patto che non vi agitiate, inserirli in com.company è una soluzione ragionevole.

L'avvertimento qui è che questo richiede che la disciplina li trasferisca in pacchetti separati ogni volta che noti gruppi di comunanza organizzativa.

Nel caso del tuo esempio, hai già iniziato a fare questi collegamenti - Il tuo post è di per sé segmentato suggerire questi pacchetti aggiuntivi:

com.company.dataaccess 
com.company.error 

AbstractDocument.java probabilmente non merita è proprio pacchetto - ancora . Se si finisce per creare interfacce/classi più correlate, spostarle in un pacchetto appropriato, ma non prendere in prestito problemi preoccupandoci finché non diventa un problema.

Answer 2

Non credo che nel tuo caso dovresti creare un pacchetto common. Immagino che qualcosa non funzioni con le astrazioni usate.

È necessario trovare un modo per unire classi con lo stesso scopo in alcuni pacchetti e posizionare questo pacchetto sotto com.company.shared.<feature_name>.

Nel tuo caso potrebbe essere:

• com.company.shared.database
• com.company.shared.data_parsing

non è un problema per un pacchetto contenga solo una o due classi. Ma dovrebbe unire solo le classi con lo stesso scopo e avere un nome parlante chiaro.

Evitare tali nomi per entrambi i pacchetti e le classi come common. Un nome dovrebbe parlare da solo.