Confusione pacchetto per caratteristica per le librerie

3

A quanto ho capito, è generalmente consigliato il pacchetto per feature piuttosto che per livello. Ciò promuove livelli più alti di astrazione e modularità tra le classi.

Riesco a capire come funziona in normali applicazioni non di utilità in cui ha funzioni chiare ( registration , security , ecc.), ma è difficile applicarlo alle librerie di utility statiche.

Ad esempio, dai un'occhiata a struttura di packaging di Google Guava . Poiché è una libreria, è difficile classificare le funzionalità della libreria in pacchetti. C'è un pacchetto annotations , un pacchetto networking , ecc. Mi sembra un po 'una zona grigia perché non è pacchettizzato in un formato esplicito?

Qual è il consenso generale quando impacchettate per feature per qualcosa che consiste in classi di utilità (come una libreria / API)?

    
posta Tim Rue 26.02.2017 - 22:05
fonte

1 risposta

1

Probabilmente il consenso generale non esiste. Logicamente, non ha senso seguire comunque il consenso generale. Dovresti creare un pacchetto in base alle astrazioni che hanno più senso per gli utenti della libreria. Se stai creando una libreria di basso livello, le astrazioni dovrebbero essere di basso livello.

La parola "caratteristiche" non ha molto significato nella tua domanda. Sono funzionalità a livello di applicazione? In tal caso, ciò potrebbe avere senso per una libreria a livello di applicazione, ma non per qualsiasi altro tipo di libreria.

    
risposta data 27.02.2017 - 20:11
fonte

Leggi altre domande sui tag