Ho il seguente caso. L'utente può esportare diversi tipi di oggetto (transazione, fattura, ecc.) Al sistema di contabilità esterna. algoritmo Export ha passi:L'implementazione di UseCases simili è simile alla duplicazione del codice
- fetch degli oggetti da parte di alcuni filtri
- oggetti uno ad uno per il sistema contabile (metodo di servizio Web per tipo di oggetto)
- registrare il fatto che la data del documento è stato esportato, in modo da esportazione E 'abitudine essere esportato di nuovo
- preparano sintesi per l'utente (num di documenti esportati, i messaggi di errore, ecc)
l'algoritmo è lo stesso per tutti i tipi di oggetti, ma ci sono alcune differenze importanti che devono essere trattate:
- diversi tipi
- diverso metodo di servizio Web di destinazione, oggetto diverso da mappature DTO
- diversi filtri per tipo di oggetto
ho considerato un poche soluzioni:
- non trattare l'algoritmo di esportazione come duplicazione del codice e implementare un algori thm per tipo di oggetto. L'esportazione di qualsiasi dato su qualsiasi sistema esterno può essere descritta da tale algoritmo - vuol dire che dovremmo sempre avere una classe generale per esportare qualsiasi cosa ovunque? :)
- spostare le differenze in strategie (un'interfaccia di strategia per creare astrazione per tutte le differenze) - L'ho persino implementato.
- uso farmaci generici - purtroppo sto codifica in PHP e non è possibile
La domanda:
è la creazione di un algoritmo di esportazione distinta per oggetto digitare una duplicazione di codice?
Forse tutti dovrebbero essere trattati come casi d'uso separati?
Se si tratta di una duplicazione, quali sono le tecniche da evitare?
Descrizione della mia prima implementazione:
In primo approccio ho definito un'astrazione esportabile ma non ero felice. Ogni oggetto ha un carico utile completamente diverso. Un'interfaccia esportabile ha definito solo un metodo getId ed è stato utilizzato per registrare quell'oggetto esportato (e grazie a ciò non verrà più esportato). A tale scopo l'astrazione andava bene, ma il problema è stato spostato su exportService che doveva verificare l'istanza concreta per scegliere il mapper e l'endpoint DTO. Quindi exportService ha rotto SOLID.
Ottima domanda. Hai preso in considerazione le relazioni * «include» * e * «estendere» * tra i tuoi casi d'uso? Probabilmente avrebbero aiutato qui. Anche alcuni pattern come * Framework *, * Extensibility * o * Template Method * potrebbero essere un'alternativa ai tuoi approcci di implementazione. – Waog
Innanzitutto, è necessario visualizzare il filtro ed esportare come due diversi problemi. Di solito vuoi spostare le differenze in strategie e nascondere la selezione delle strategie dietro a una facciata/fabbrica in base al modo in cui la tua API è progettata. Ad esempio, il client potrebbe eseguire solo "exportService.export (listOfExportable)", ma internamente basato sul tipo di "Esportabile", verrà scelto un endpoint del servizio Web e un assembler dto. Il servizio di esportazione potrebbe essere reso configurabile dall'esterno per evitare di violare il principio di open-closed. È anche possibile impostare la strategia su Esportabile – plalx
Il vantaggio di consentire all'esportabile di specificare le strategie consente di evitare l'utilizzo del modello di localizzazione del servizio all'interno del servizio di esportazione. ExportService potrebbe semplicemente inviare due volte su "Esportabile" per raccogliere le informazioni. Allo stesso tempo, c'è uno svantaggio dal momento che i problemi infrastrutturali potrebbero essere trapelati a livelli dove non dovrebbero. Questa è una lotta simile a "dovrei inserire annotazioni ORM in un'entità o dovrei usare file XML esterni?". – plalx