qué - c#clase abstracta implementando una interfaz

polimorfismo c#

Question

He visto los siguientes foros de lectura de diseño de código y otras publicaciones de blog y he adaptado para hacer algunas preguntas.

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);
}

Lo que no entiendo es el beneficio de que la clase abstracta implemente la interfaz. Para mí, me parece un poco repetitivo y no puedo entender el beneficio de tener una clase abstracta implementando la interfaz.

1. ¿Por qué la clase abstracta ServiceBase<T> no se define tal como está sin la necesidad de heredar la interfaz IService? ¿Esto está duplicando el código?
2. ¿Por qué el SomeBaseClass también implementa el servicio ICarService ? ¿No debería ser suficiente la base de servicio?

Answer 1

Anuncio 1: la clase base abstracta adicional le permite evolucionar la interfaz sin romper la implementación. Supuso que no había una clase base abstracta, y extendería la interfaz, digamos agregando un nuevo método. Entonces su implementación se rompió, porque su clase ya no implementa la interfaz.

Usando una clase base abstracta adicional, puede separar esto: si agrega un nuevo método a la interfaz, puede proporcionar una implementación virtual en la clase base y todas sus subclases pueden permanecer iguales y pueden ser adoptadas para que coincidan con las nuevas interfaz en un momento posterior en el tiempo.

Además, esta combinación le permite definir un contrato (mediante la interfaz) y proporcionar algunos mecanismos predeterminados (mediante la clase base abstracta). Cualquiera que esté de acuerdo con los valores predeterminados puede heredar de la clase base abstracta. Cualquiera que desee un control fino super-duper sobre cualquier pequeño detalle puede implementar la interfaz manualmente.

Anuncio 2: desde un punto de vista técnico, no hay NECESIDAD de implementar la interfaz en la clase final. Pero esto, de nuevo, te permite evolucionar las cosas por separado. Un CarService es sin duda un Service<Car> , pero quizás sea aún más. Tal vez solo un Servicio de CarService necesite algunas cosas adicionales que no deberían ir a la interfaz común ni a la clase base de servicio.

Supongo que por eso ;-)