Design - Parser.hasInfo (MyClass) vs MyClass.hasInfo ()

Question

Design - Parser.hasInfo (MyClass) vs MyClass.hasInfo ()

#1 da (2 voti)
#2 da (2 voti)

3

Sto lavorando su un sistema di elaborazione dei documenti.

Sono fiducioso con una classe Document che rappresenta ciascun documento in elaborazione.

Il problema:

Ogni Document può avere un CoverSheet , e se lo fa, dobbiamo ottenere CoverSheetInfo da questo CoverSheet (per la ridenominazione e l'elaborazione). Ma il controllo di una CoverSheet e la forzatura delle informazioni in CoverSheetInfo comportano una discreta quantità di codice Apache PDFBox.

Sto cercando di decidere quale sia il posto migliore per avere questa funzionalità.

Opzione 1

Document class avrà questi metodi:

public boolean hasCoverSheet()

public CoverSheetInfo getCoverSheetInfo()

Pro:

Il comportamento è vicino ai dati: il processo di controllo di Document per un CoverSheet avviene in Document che sembra ragionevole.

Contro:

Questo aggiunge molte linee di parsing relative a PDFBox che rendono l'altro saggio semplice set-get Document disordinato e rende la classe Document superiore a 300 righe per includere questa funzionalità. Quindi opzione 2 ...

Opzione 2

Crea una classe DocumentParser che avrebbe:

public boolean hasCoverSheet(Document document)

public CoverSheetInfo getCoverSheetInfo(Document document)

Pro:

Tutto il codice di analisi specifico per PDFBox si trova nella propria classe. Penso che questo sia un buon esempio di rafforzamento della Single Responsibility / Law of Demeter Siccome non penso che Document debba necessariamente sapere come analizzare le informazioni dai fogli di copertina.

Contro:

Awkward (?) separazione del comportamento dai dati (?)

Quale sembra il più ragionevole e in che modo?

Modifica: sono disperato. Qualsiasi feedback sarebbe assolutamente. fricken. amato.

Modifica 2

Un Document è in questo caso un documento ipotecario scansionato, e sempre sarà un PDF. Una Document viene creata quando la mia app trova i file in una directory (viene creato un Document per ogni file trovato). DocumentParser dovrebbe elaborare Documents , a destra, File è stato un errore di battitura.

A questo punto, Document è essenzialmente un wrapper attorno al File. In Opzione 1 , avrebbe CoverSheetInfo come campo e File stubFile e boolean riguardo all'esistenza di queste cose.

Ecco la "storia" per quello che sto facendo:

Qualcuno scannerizzerà un documento. Finirà in una directory. La mia app ha bisogno di guardare quella directory, e

rinomina i file con la loro copertina (se ne hanno uno)
crea uno stub delle prime 8 pagine (se il file è molto grande)
carica questi file (e tutti gli stub creati) su Google Drive.

design java class-design

posta mmcrae 14.10.2014 - 02:29

fonte

2 risposte

2

Perché non hai un oggetto CoverSheet separato? Quindi puoi fare in modo pulito

CoverSheetInfo coverInfo = null;
if(theDocument.hasCoverSheet()) {
    CoverSheet cover = theDocument.getCoverSheet();
    coverInfo = cover.getInfo();
}

Scusa, non ho familiarità con PDFBox, quindi non so se questo introduce più complessità di quanto risolva, ma (IMHO) è un design molto più pulito.

risposta data 14.10.2014 - 18:30

fonte

Leggi altre domande sui tag design java class-design

OOP - Classe Manager separata Se memorizzare tutti i numeri o solo i loro intervalli nel database per questa applicazione

score 2 · Accepted Answer

Per quanto ho capito, la copertina è una proprietà importante di un documento nella tua applicazione. Quindi lo rappresenterei con un getter. Le classi di business che si occupano di rinominare il documento richiedono solo l'oggetto Document e non hanno alcuna dipendenza da un parser a cui non interessa.

Come viene implementato quel getter è una domanda diversa. Ad esempio, è possibile fornire un'implementazione fittizia che fornisce una copertina predefinita per il test dell'unità. Per risolvere il problema di una lunga classe con più responsabilità, è possibile estrarre il codice di analisi in una classe separata utilizzata dall'implementazione% Document .

Per fare un ulteriore passo avanti, l'istanza parser potrebbe essere fornita al costruttore Document . Si chiama iniezione di dipendenza e decodifica il parser dal documento, in modo da poter utilizzare altri parser. Ad esempio, il test unitario di Document può utilizzare un'implementazione fittizia del parser. Esistono framework come weld che forniscono essenzialmente una factory per creare classi senza conoscere la dipendenza esatta (cioè il parser).