Va bene avere dipendenze all'interno di una classe che deve essere scambiabile?

Con riferimento a la mia risposta a una domanda recente , la chiave qui è di separare le interfacce del livello di persistenza da qualsiasi implementazione del livello di persistenza, utilizzando il modello di scala.

La dipendenza dal serializzatore Json diventa quindi un dettaglio di implementazione del pacchetto di persistenza Json. Il resto dell'applicazione non ha bisogno di sapere nulla al riguardo, né deve sopportare l'onere di tale dipendenza poiché accede solo al pacchetto di persistenza tramite le interfacce, che si trovano in un altro pacchetto.

Se si aggiunge un pacchetto di persistenza del database, implementa semplicemente tali interfacce e le sue dipendenze, ad esempio ORM, sono anch'esse nascoste come dettagli di implementazione.

Non puoi rimuovere tutte le dipendenze dal tuo codice; alla fine devi dipendere da qualcosa , altrimenti finirai con un gigantesco oggetto-dio che fa tutto da solo.

Come regola generale, vuoi che ogni classe dipenda da oggetti che saranno più stabili di loro stessi; e desideri relazioni instabili per utilizzare l' iniezione di dipendenza per consentire test più semplici e maggiore flessibilità.

Quanto è probabile che il serializzatore JSON cambierà? È più o meno stabile del codice che stai scrivendo?

Se è probabile che sostituirai il serializzatore più di una volta con un'implementazione diversa, forse puoi creare un proxy o un oggetto wrapper attorno al serializzatore stesso. In questo modo, puoi controllare l'interfaccia che hai con il serializzatore e dipendere solo da una libreria esterna in un unico posto.

Detto questo, personalmente non ho ancora trovato un motivo per sostituire un serializzatore JSON (con un serializzatore diverso), quindi non mi preoccuperei troppo di avere una dipendenza diretta su di esso. Un serializzatore ha quasi sempre un'interfaccia più stabile di qualsiasi altra nelle mie applicazioni e i metodi che ho bisogno sono così semplici e pochi che non c'è davvero un motivo per cambiarli.

Sembra che tu non sia preoccupato in particolare del serializzatore stesso che cambia tuttavia - da quello che hai descritto, sei preoccupato che i requisiti esterni cambino in un sistema di persistenza totalmente diverso - nel qual caso, l'implementazione del livello di persistenza verrà comunque completamente riscritta e l'utilizzo di dependency injection o di un proxy non ti aiuterà.

Finché l'interfaccia tra il livello di persistenza e i modelli di dominio rimane la stessa, e stai prendendo in giro quel livello di persistenza quando collaudi i tuoi modelli di dominio, non vedo alcun problema a seconda dell'interfaccia specifica di una libreria JSON. Questa dipendenza è economica da testare e la stessa libreria JSON non dovrebbe cambiare.