Iniezione delle dipendenze e utilizzo delle interfacce?

Question

Ho notato che molti sviluppatori definiscono un'interfaccia per la classe OGNI che verrà iniettata usando il framework DI. Quali sono i vantaggi della definizione di interfacce per ogni classe?

Answer 1

Lasciando i vostri componenti dell'applicazione (le classi che contengono logica dell'applicazione) implementare un'interfaccia è importante, dal momento che questo ha promosso il concetto di:

programma a un'interfaccia, non un'implementazione.

Questo è effettivamente il Dependency Inversion Principle. Ciò consente di sostituire, intercettare o decorare dipendenze senza la necessità di cambiare i consumatori di tale dipendenza.

In molti casi, gli sviluppatori violano i principi SOLID quando hanno un mapping quasi uno a uno tra le classi e un'interfaccia. Uno dei principi che è quasi certamente violato è lo Open/closed principle, perché quando ogni classe ha una propria interfaccia, non è possibile estendere (decorare) un insieme di classi con preoccupazioni trasversali (senza l'inganno di generazione di proxy dinamico che è).

Nei sistemi che scrivo, definisco due interfacce generiche che coprono la maggior parte del codice del livello aziendale. Essi sono chiamati ICommandHandler<TCommand> e un IQueryHandler<TQuery, TResult>:

public interface ICommandHandler<TCommand> 
{ 
    void Handle(TCommand command); 
} 

public interface IQueryHandler<TQuery, TResult> where TQuery : IQuery<TResult> 
{ 
    TResult Handle(TQuery query); 
} 

Oltre l'effetto collaterale di non dover definire molte interfacce, questo consente una grande flessibilità e facilità di test. Puoi leggere di più su di esso here e here.

A seconda del sistema che scrivo, mi potrebbe anche utilizzare interfacce come:

• IValidator<T> per la convalida dei messaggi
• ISecurityValidator<T> per l'applicazione di restrizioni di sicurezza sui messaggi
• IRepository<T>, il modello repository
• IAuthorizationFilter<T> per l'applicazione del filtro di autorizzazione/sicurezza sulle query IQueryable<T>.

A seconda del sistema che scrivo, da qualche parte tra l'80% e il 98% di tutti i componenti implementano una di queste interfacce generiche che definisco. Questo rende banale l'applicazione di problemi trasversali a quelli così chiamati joinpoints.

Answer 2

Questo blog ha un sacco di risposte che stai cercando: http://benpryor.com/blog/2006/08/23/java-advantages-of-interfaces/

Se non si progetta per le interfacce, che si sta per essere ostacolati quando arriva il momento di refactoring del codice e/o aggiungere miglioramenti. L'utilizzo di un framework DI non è realmente in discussione quando si tratta di progettare un'interfaccia. Ciò che DI ti dà è la capacità di legare in ritardo e molto meglio scrivere test di unità.