Nella nostra azienda abbiamo un'architettura orientata ai servizi nella nostra applicazione asp.net. Utilizziamo le interfacce per ogni classe di crap. È un enorme sovraccarico. Le classi di servizio, le classi dataprovider ecc ... usano tutte le interfacce ma praticamente potremmo anche andare senza queste interfacce e usare solo il tipo di classe.
Quindi perché dovremmo farlo così complicato e perdere molta produttività?
Credo che avere un'interfaccia per la classe ogni sia programmazione culto cargo .
Hai bisogno di interfacce / classi astratte quando cambierai / cambi le implementazioni. Sono anche la facile risposta per le dipendenze derisorie nei test delle unità.
Quello che stai descrivendo è un anti-modello. Un anti-pattern è un pattern che viene solitamente applicato a tutte le situazioni anche quando è appropriato.
Qualcuno probabilmente ha letto un articolo che ha sposato questo anti-pattern per alcune aree di nicchia, e non ha compreso la stretta applicazione e la applica ovunque. Questo accade molto con gli sviluppatori "senior" che sono solo "di ruolo" e non in realtà senior nella conoscenza, o manager che sono solo abbastanza tecnici da essere pericolosi. Forse qualcuno da uno sfondo C ++ che manca il noioso paradigma di dichiarazione / definizione.
Vedi anche "modello di martello", quando tutto ciò che sai è un martello, tutto sembra un chiodo.
Questo è basato sui miei 20 anni di esperienza che hanno visto questa stessa identica dozzina di volte.
In primo luogo, le interfacce sono solitamente delle dipendenze più semplici da riempire / schernire quando si esegue il test delle unità, perché il comportamento predefinito è ... nulla, quindi si può essere sicuri di testare le classi in modo isolato.
In secondo luogo, quando hai bisogno di creare una simulazione personalizzata, non devi fare niente di speciale, basta scrivere una classe che eredita l'interfaccia. Ciò semplifica la fornitura delle dipendenze alle tue classi durante i test e, a volte, l'implementazione di simulazione è la seconda implementazione che stai cercando.
In terzo luogo, se stai solo scrivendo una classe, fai clic con il tasto destro del mouse su > estrai l'interfaccia ogni volta, non stai interpretando correttamente la "I" in "SOLID". La segregazione dell'interfaccia implica che le interfacce siano progettate per il CLIENT dell'interfaccia e non per corrispondere all'implementazione. C'è una differenza importante in quanto il primo tipicamente produrrà un design più liberamente accoppiato. A volte è una linea molto sottile, ma vale la pena tenerla d'occhio.
Ovviamente, se non sei interessato ai test unitari e non sei interessato a SOLID, codice manutenibile e verificabile, allora sì ... le interfacce potrebbero non avere molto valore pratico se non hai implementazioni multiple in fase di esecuzione.
Leggi altre domande sui tag programming-practices interfaces architecture .net soa