Sto leggendo il libro Clean Code e un capitolo dice che se una classe ha più di 3 dipendenze è un odore di codice di quella classe non sta facendo una cosa. O che cosa è lo stesso, non sta seguendo SRP. Sto pensando in alcuni scenari in cui non riesco a resettare il numero di dipendenze per rispettare quel numero.
Diciamo che abbiamo un'app che si collega a un REST API pubblico che offre varie informazioni su molte entità nel nostro dominio. Nella nostra app rileviamo un caso d'uso ripetuto in molti luoghi in cui richiediamo all'API le informazioni su un'entità con altre entità dipendenti che ha.
L'API REST non offre i dati nel formato che vogliamo perché le chiamate quando possono effettuare sono ottenere dati da una singola tabella sul database web, non offre i dati raggruppati con altre tabelle come vogliamo. Quindi il nostro caso d'uso deve fare diverse Api Call per ottenere tutti i dati diversi sulle entità di cui abbiamo bisogno e quindi fonderci nel modello che useremo nell'app.
Per connettersi con il sottosistema esterno nascondiamo l'implementazione in una singola classe di servizio, tuttavia questa classe è cresciuta troppo, risultando una classe con molti metodi per ottenere dati su tutte le entità del resto della api. Quindi abbiamo diviso questa enorme classe in differenti seguendo il modello del repository. Ogni classe per ogni operazione possibile con un'entità sull'API.
Quindi, per nascondere tutta questa interazione concreta e comune con il livello di servizio useremo una classe Facade per coordinare tutte queste chiamate. Il problema che sto pensando che avrà, è che avrà molte dipendenze nel suo costruttore. Disporrà di classi per ogni classe di repository e classi di mapper per adattare i dati web ai dati delle app.
La soluzione in questi casi è unire tutte le dipendenze correlate in una in modo da ridurre il numero. Un esempio è questo: Refactoring to Aggregate Services. link
Ma ti unisci quando vedi una relazione chiara. Cosa succede se nella tua classe non riesci a vederlo? Tutte le classi sono granulate ma sono tutte necessarie per raggiungere l'obiettivo ma non possono essere unite in un servizio aggregato.
Quindi la mia domanda è: la "regola" secondo cui più di tre dipendenze viola l'SRP è sempre applicabile? Tornando al nostro esempio, la nostra facciata deve accedere a molte classi di repository e classi di mapper. Le classi di mapper possono essere nascoste su un servizio aggrovigliato, forse, ma le classi di repository vanno bene come sono. Potremmo introdurre un localizzatore di servizio per memorizzarli, ma è una pessima pratica.