С# Абстрактный класс, реализующий интерфейс

Я видел следующий код, читающий форумы и другие сообщения в блогах, и адаптированный для того, чтобы задать несколько вопросов.

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

То, что я не понимаю, - это преимущество того, что абстрактный класс привносит интерфейс. Для меня это просто немного повторяется, и я не могу понять, что имеет абстрактный класс, реализующий интерфейс.

  • Почему абстрактный класс ServiceBase<T> просто не определяется, так как нет необходимости наследовать интерфейс IService? Это удвоение кода?
  • Зачем нужно SomeBaseClass внедрять ICarService? Должна ли ServiceBase быть достаточной?

Ответы

Ответ 1

Объявление 1: дополнительный абстрактный базовый класс позволяет вам развивать интерфейс без нарушения реализации. Предполагалось, что не было абстрактного базового класса, и вы бы расширили интерфейс, допустим, добавив новый метод. Тогда ваша реализация была нарушена, потому что ваш класс больше не реализует интерфейс.

Используя дополнительный абстрактный базовый класс, вы можете отделить это: если вы добавите новый метод в интерфейс, вы можете предоставить виртуальную реализацию в базовом классе, и все ваши подклассы могут оставаться неизменными и могут быть приняты в совместим новый интерфейс в более поздний момент времени.

Кроме того, эта комбинация позволяет вам определить контракт (используя интерфейс) и предоставить некоторые механизмы по умолчанию (используя абстрактный базовый класс). Любой, кто штрафует значения по умолчанию, может наследовать от абстрактного базового класса. Любой, кто хочет супер-пупер тонкого контроля над любой небольшой деталью, может реализовать интерфейс вручную.

Объявление 2: С технической точки зрения НЕОБХОДИМО реализовать интерфейс в конечном классе. Но это, опять же, позволяет вам развить вещи отдельно друг от друга. A CarService - это точно Service<Car>, но, возможно, это еще больше. Возможно, только для CarService нужны дополнительные материалы, которые не должны входить в общий интерфейс или в базовый класс службы.

Я думаю, почему: -)