Design Pattern per estrarre il campo arbitrario dal formato di file arbitrario

Indipendentemente dal pattern che usi qui, la cosa fondamentale è decidere cosa intendi modellare: qualunque sia il file o ciò di cui l'applicazione ha bisogno.

Ci sono casi d'uso per entrambi. Un editor di testo può caricare un file .json o .csv, ma mentre può mostrare il tuo campo arbitrario e il suo valore, non ha idea di cosa fare con esso oltre a mostrarlo a te. L'editor di testo rigurgita solo il file senza comprenderlo. La tua applicazione potrebbe fare lo stesso. In questa situazione non si fa alcuna logica contro il campo. Rileva il formato del file e presenta il file in base al formato e la strategia funziona correttamente se vuoi presentare diversi formati in modo diverso. Qui si lascia che l'utente si occupi della comprensione del campo arbitrario.

Se hai bisogno di utilizzare il campo arbitrario in alcune logiche di business, allora ti trovi in una situazione diversa. Ti aspetti che alcune qualifiche esistano, che la logica vada avanti e che non esistano modi per affrontarle. Hai ancora bisogno di rilevare e gestire il formato del file, e la strategia funziona ancora per questo, ma ora hai bisogno di costruire una struttura dati accessibile che capisca questo campo arbitrario e, indipendentemente dal formato del file, funzioni allo stesso modo per tutto il business logica che stai utilizzando contro questo campo arbitrario.

Potrebbe essere utile capire che è raro avere solo un campo in questo caso successivo. Di solito ne trovi alcuni che possono essere raggruppati per formare un'idea coerente. Potrebbero diversi di questi gruppi in un unico file. Questi raggruppamenti diventano strutture dati, oggetti di trasferimento dati, POJO. Se hanno un'identità che va oltre i propri valori, diventano entità.

Ottenere i dati dal file in memoria non è banale. A volte è semplice perché il file segue da vicino quello che ti serve in memoria, ma non è sempre così e alcune conversioni devono essere fatte. Quando si verifica questo problema con i database, viene chiamato disadattamento dell'impedenza relazionale all'oggetto .

Indipendentemente da tutto questo, quando ti trovi nella situazione in cui il tuo codice deve comprendere il campo arbitrario, è meglio iniziare il tuo progetto ignorando il file e concentrandoti sulle esigenze delle tue app. Supponiamo che otterrai il campo in qualche modo se esiste. Esprimi che ne hai bisogno lasciandolo passare da qualcosa. Usalo comunque è necessario.

Solo una volta che hai finito scrivi il codice che va, lo trova e lo passa dove è necessario. Una buona tecnica per questo è l'iniezione di dipendenza. Ciò ti consente di separare l'utilizzo del campo arbitrario dalla costruzione di qualsiasi struttura dati che utilizzi per modellarlo.

Non c'è una soluzione magica a questo. Se i formati di file contengono alcune informazioni sulla versione incorporate, è possibile utilizzare tali dati, inserirli in una Factory e creare l'istanza appropriata di una strategia per la lettura. Potresti anche avere strategie separate per l'elaborazione di tali dati. Il grado in cui sarai in grado di condividere la logica tra di loro dipenderà dal numero di astrazioni utili che puoi creare (in base alla tua conoscenza di ciò che l'applicazione fa), per costruire il tuo sistema intorno a loro.

L'idea alla base del modello di strategia, e qualsiasi altro modello che deve essere agnostico dei dettagli di implementazione, è scrivere codice contro un'astrazione (come un'interfaccia) e avere qualche altro supporto specifico per l'implementazione che l'astrazione.

Dovraicreareun'interfacciaabbastanzagenerale,maallostessotempoabbastanzautileaffinchél'applicazionepossacontinuareasvolgereillavorochedevesvolgere,perchéaunlivellosuperiorenonpuoifareriferimentoaicampididatichepotrebbeessereunivocoperunformatodifileeunaversionespecifici(oaltridettaglispecificidelformato,comelastruttura,l'ordine,ecc.).Incasocontrario,dovrestigestireognicasoinmododiversoeciòpotrebbelimitarel'estensibilitàelamanutenibilità;l'ideaèdicontenerequestocomportamentospecificodelformatoinunaclassedilivelloinferioreoinunaraccoltadiclassicorrelate.Quindidevipensareacosafalatuaapplicazione,eseèpossibileesprimerelalogicainterminidilivellosuperiore(cioèdovrestiessereingradodidiresemplicementeilcodiceDoATask()elasciarecheunasottoclassespecificaperilformatogestisca,invecediReadDataField(...);DoStuffWithDataField(...);).

Unaltroapprocciopossibile(chepotrebbeesserecomplementareaquellochehodescrittosopra)èquellodicreareunasortadimodellodidatiunificatochel'applicazioneutilizzeràinternamente.Ivarilettorididatispecificidelformatodovrebberoleggereidatieconvertirliinquestoformatounificato,eil"nucleo" della tua applicazione lo prenderebbe (funzionerebbe esclusivamente con i dati in quella forma). Ciò richiederebbe la scrittura di un codice boilerplate (per tradurre in / dal formato interno), e potrebbe esserci o meno un successo nelle prestazioni. Ma il design è solo una questione di compromessi, quindi devi valutare i pro e i contro.

P.S. Se non sono disponibili informazioni sulla versione, è possibile che tu possa utilizzare la tua conoscenza dei domini per controllare in qualche modo il file e determinare (beh, indovinare) il formato del file, in base a qualcosa come la struttura del file. Ma questo (1) potrebbe non essere sempre possibile, e (2) anche quando è possibile, può essere inaffidabile e può ritorcersi contro.