Is 20 Java classes for just making...
Questa è completamente la domanda sbagliata. Qualcosa non va o non te lo chiederesti. Sembra che tu stia cercando qualcosa da incolpare. Angosciare il numero di classi non ha intenzione di risolverlo.
Ho sentito prima questo stesso dolore. Fai un passo indietro e guarda tutto. Funziona. Puoi un po 'seguirlo. Ma lo sai guardarlo più tardi sarai perso. Non ti piace. Vuoi aggiustarlo ora mentre puoi seguirlo. Impostare un limite sul numero di classi perché stai solo provando a fare x non lo risolverà.
Ciò che verrà risolto è l'astrazione.
Perché pensi che ci siano 20 classi? Può essere perché tutti si mostrano in un posto, quindi ora devi pensarci tutti insieme. Questo è ciò che è male.
20 è un numero grande. 4 e 5 non lo sono. Non mi dispiacerebbe vedere 4 gruppi con 5 classi che lavoravano insieme. Questo è ancora 20. È solo organizzato, quindi è più facile da guardare.
A volte una struttura per l'iniezione di dipendenza rende facile assumere un atteggiamento procedurale nei confronti della costruzione. Basta creare una pila di collegamenti tra oggetti che non hanno alcuna struttura. È facile da scrivere Non è così facile da leggere.
Se li hai riversati tutti in un unico file che definisce il modo in cui si collegano, guardi l'intero grafico dell'oggetto contemporaneamente. Con solo 5 classi che possono iniziare a essere dolorose. Trova alcune separazioni logiche. Rompi le cose. Raggruppa gli oggetti che hanno a che fare l'uno con l'altro. Separa quelli che non lo fanno.
Una grande cosa che può aiutare con questo è modelli creazionali. Quando esponi ogni dipendenza posseduta da un oggetto, rendi la cosa fastidiosa. Un buon builder ti permette di separare le dipendenze che cambiano spesso dalle dipendenze che non lo fanno. Piuttosto che nascondere le dipendenze nell'oggetto, le nascondi nel builder. Quando sono disponibili buone impostazioni predefinite dovrebbero essere facili da usare.
Per quanto riguarda le interfacce che stai salvando qui hai detto "quasi". Odio quando le persone estraggono ciecamente le interfacce senza pensare a quello che stanno facendo. È completamente indietro pensare un'interfaccia APPARTIENE alla classe che la implementa. No, i clienti hanno l'interfaccia. L'interfaccia esiste PER IL CLIENTE, DEVE ESSERE DEFINITA DAL CLIENTE E POTREBBE NON ESSERE MAI CAMBIATA SOLO AL CONSENSO DEL CLIENTE. Se ti capita di essere un oggetto che implementa quell'interfaccia, fa bene a te. Adesso stai zitto e fai quello che ti viene detto. Il cliente non vuole neanche sapere che esisti.
Detto questo, mi piacciono le interfacce. Principalmente perché quando scrivo clienti che si riferiscono a loro e non a implementazioni non sono tentato di usarne di nuovi. La grande eccezione a questo è oggetti valore. Le stringhe non hanno bisogno di creare interfacce per loro. Se utilizzi altri oggetti valore, anche quelli di tua progettazione, generalmente non gli dai un'interfaccia , non dovresti dare loro un comportamento, non hai bisogno di testarli e non dovresti mai cambiarli. Sai, come le stringhe.
Ora, se stai parlando di un oggetto comportamentale che deve effettivamente riflettere, prova quella dannata cosa.
Se stai facendo MVP, configurando i componenti, i moduli e gli ambiti dei pugnali, stai facendo molto di più del semplice REST.