Java "module" size

4

È ragionevole disporre di micromoduli, ad esempio con solo una pochissima (forse una) classe? O dovrei memorizzare cose in repository più grandi?

Sono uno sviluppatore Java di lunga data con un background di ingegneria del software. Cerco di scrivere codice OO ben incapsulato e focalizzato. Ho scritto in precedenza codice in grandi moduli / progetti / archivi con modulo principale a seconda dei moduli "comuni".

I moduli "comuni" sembrano essere un odore di codice allo stesso modo delle classi comuni / utili - un segno che qualcuno non ha pensato a quale sia l'incapsulamento reale e pulito.

Ora sto cercando di pubblicare alcuni articoli su un blog e di eseguirne il backup con codice su BitBucket, con 1 articolo con il proprio modulo e amp; repository.

Mi piacciono le dipendenze pulite, l'odio della duplicazione, ecc. e ci sono dipendenze naturali verso il basso da 1 modulo a codice "comune".

Java non semplifica la gestione delle dipendenze (si spera risolta in Java 9 con Jigsaw), ma è interessante notare che Google Dart ha un meccanismo molto carino e sembra raccomandare moduli piccoli e stretti (e presumibilmente repository per modulo).

Sto pensando a piccoli moduli di Java, con dipendenze Maven. Ogni modulo nel proprio repository. Jar è pubblicato su un sito di esperti.

EDIT: 1) Voglio scrivere alcuni post del blog. Ogni post riguarderà un argomento diverso. Ogni argomento riguarderà un modulo coesivo di codice. Voglio che i lettori siano in grado di scaricare il modulo di codice per il post.

2) Sto usando Bitbucket come mio repository git. Punto 1) implica (?) Che ho bisogno di un repository per modulo / articolo del blog.

3) Sto cercando di fare le cose ragionevolmente correttamente: non c'è bisogno di perfezione

4) Gli articoli del blog sono solo una parte di questo: voglio una buona decomposizione in moduli per ragioni di ingegneria del software sonoro.

5) Non sono ancora pronto a rendere pubblici i miei repository, sono incompleti, ma questi sono i moduli che attualmente sto pianificando: - 5a) Validazione: solo una singola classe con validazione utile (mi piacciono le cose simili a DbC!) 5b) Generatore HTML - bel modulo per generare HTML da Java - dipende dalla convalida 5c) Componente Swing "panning" - di nuovo dipende dalla convalida

6) Ciascuno dei moduli in 5) dipende dalla convalida e sono anche moduli discreti.

Quindi, dovrei avere 6a) 3 x repository (permettendo alle persone di scegliere e mixare facilmente) 6b) 1 x repository che costruisce un singolo barattolo 6c) 1 x repository che costruisce 3 x jar, 1 per "module"

    
posta David Kerr 09.10.2013 - 14:06
fonte

1 risposta

1

Quando penso a Java tendo a pensare ai pacchetti , non ai "moduli", ma suppongo di essere troppo back-end / orientato all'API. I moduli sono orientati front-end / case-use e dovrebbero essere principalmente nel livello view / controles.

Nel livello di logica aziendale / modello non dovresti preoccuparti della dimensione del "modulo", dato che le classi, le interfacce, ecc. sarebbero nei pacchetti.

Nel controller di presentazione / visualizzazione si può pensare alla dimensione del "modulo", ma poi non è chiaro cosa può essere considerato "grande". Per me, large riguarda le righe di codice , non il numero di classi. Ciò che mi preoccupa sono le dimensioni delle classi, non il loro numero.

Le dimensioni di un modulo sono principalmente dettate dai casi d'uso e dalle funzionalità che l'applicazione avrà. Pensi che un dato schermo stia facendo troppo?

In conclusione, se stai facendo bene il design orientato agli oggetti, non dovresti preoccuparti del numero di classi. Preoccupati per le classi con troppe righe di codice o schermate / applicazioni che fanno troppo.

EDIT: Intendo davvero l'incapsulamento di idee più grandi di una singola classe e il riutilizzo del codice in più progetti.

Un pacchetto di esempio potrebbe essere una finestra di dialogo Swing che ha una classe pubblica pubblica che il codice client dovrebbe usare e un numero qualsiasi di classi di implementazione che il codice client non dovrebbe vedere . Java lo rende difficile (fino a Jigsaw). Questo pacchetto dovrebbe essere un modulo (il proprio jar) se è condiviso sui progetti, o dovrebbe essere raggruppato in un grande progetto "shared-dialogs"?

    
risposta data 09.10.2013 - 14:19
fonte

Leggi altre domande sui tag