C# Classe astratta che implementa un'interfaccia

Question

Ho visto i seguenti forum di lettura del layout di codice e altri post del blog e adattato per fare alcune domande.

public interface IService<T> 
{ 
    int Add(T entity); 
    void Update(T entity); 
} 

public abstract class ServiceBase<T> : IService<T> 
{ 
    public int Add(T entity) { ... } 
    public void Update(T entity) { ... } 
} 

public interface ICarService : IService<Car> 
{ 
} 

public class SomeBaseClass : ServiceBase<Car>, ICarService 
{ 
    public int Add(Car entity); 
    public void Update(Car entity); 
} 

Quello che non capisco è il vantaggio di avere la classe astratta implmenting l'interfaccia. Per me è semplicemente un po 'ripetitivo e non riesco a capire il vantaggio di avere una classe astratta che implementa l'interfaccia.

1. Perché la classe astratta non si definisce semplicemente senza la necessità di ereditare l'interfaccia di IService? Questo sta raddoppiando il codice?
2. Perché lo SomeBaseClass deve essere inserito anche nello ICarService? Non dovrebbe essere sufficiente il ServiceBase?

Answer 1

Annuncio 1: La classe di base astratta aggiuntiva consente di evolvere l'interfaccia senza interrompere l'implementazione. Supposto che non ci fosse una classe base astratta e tu avresti esteso l'interfaccia, poniamo aggiungendo un nuovo metodo. Quindi la tua implementazione è stata interrotta, perché la tua classe non implementa più l'interfaccia.

Utilizzando una classe di base astratta aggiuntiva è possibile separare questo: Se si aggiunge un nuovo metodo all'interfaccia, è possibile fornire un'implementazione virtuale nella classe base e tutte le sottoclassi possono rimanere uguali e possono essere adottate per abbinare la nuova interfaccia in un momento successivo.

Inoltre, questa combinazione consente di definire un contratto (utilizzando l'interfaccia) e fornire alcuni meccanismi predefiniti (utilizzando la classe base astratta). Chiunque stia bene con i valori predefiniti può ereditare dalla classe base astratta. Chiunque desideri un controllo accurato del super-duper su qualsiasi piccolo dettaglio può implementare manualmente l'interfaccia.

Annuncio 2: Da un punto di vista tecnico non esiste lo NECESSARIO per implementare l'interfaccia nella classe finale. Ma questo, di nuovo, ti consente di evolvere le cose separatamente le une dalle altre. A CarService è sicuramente uno Service<Car>, ma forse è ancora di più. Forse solo un CarService ha bisogno di alcune cose aggiuntive che non dovrebbero entrare nell'interfaccia comune né nella classe base di servizio.

Credo che sia per questo ;-)