Имеет ли смысл определять интерфейс, если у меня уже есть абстрактный класс?

У меня есть класс с некоторыми функциями по умолчанию / общий доступ. Я использую abstract classдля этого:

public interface ITypeNameMapper
{
    string Map(TypeDefinition typeDefinition);
}

public abstract class TypeNameMapper : ITypeNameMapper
{
    public virtual string Map(TypeDefinition typeDefinition)
    {
        if (typeDefinition is ClassDefinition classDefinition)
        {
            return Map(classDefinition);
        }
        ...

        throw new ArgumentOutOfRangeException(nameof(typeDefinition));
    }

    protected abstract string Map(ClassDefinition classDefinition);
}

Как видите, у меня тоже есть интерфейс ITypeNameMapper. Имеет ли смысл определять этот интерфейс, если у меня уже есть абстрактный класс TypeNameMapperили abstract classего достаточно?

TypeDefinition в этом минимальном примере это тоже абстракция.

Да, потому что C # не допускает множественного наследования, за исключением интерфейсов.

Поэтому, если у меня есть класс, который является одновременно TypeNameMapper и SomethingelseMapper, я могу сделать:

class MultiFunctionalClass : ITypeNameMapper, ISomethingelseMapper 
{
    private TypeNameMapper map1
    private SomethingelseMapper map2

    public string Map(TypeDefinition typeDefinition) { return map1.Map(typeDefintion);}

    public string Map(OtherDef otherDef) { return map2.Map(orderDef); }
}

Интерфейсы и абстрактные классы служат разным целям:

• Интерфейсы определяют API и принадлежат клиентам, а не реализациям.
• Если у классов есть общие реализации, то вы можете воспользоваться абстрактным классом.

В вашем примере interface ITypeNameMapperопределяет потребности клиентов и abstract class TypeNameMapperне добавляет никакой ценности.

Вся концепция интерфейсов была создана для поддержки семейства классов, имеющих общий API.

Это прямо говорит о том, что любое использование интерфейса подразумевает, что существует (или ожидается) несколько реализаций его спецификации.

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

Ответ лежит в самом вопросе. Если у вас есть абстрактный класс, вы готовитесь к созданию более одного производного класса с общим API. Таким образом, использование интерфейса четко обозначено.

Если мы хотим явно ответить на вопрос, автор говорит: «Имеет ли смысл определять этот интерфейс, если у меня уже есть абстрактный класс TypeNameMapper или достаточно абстрактного класса?»

Ответ - да и нет - да, вы должны создать интерфейс, даже если у вас уже есть абстрактный базовый класс (потому что вы не должны ссылаться на абстрактный базовый класс в любом клиентском коде), и нет, потому что вы не должны были создавать абстрактный базовый класс при отсутствии интерфейса.

То, что вы недостаточно продумали API, который пытаетесь создать, очевидно. Сначала придумайте API, а затем предоставьте частичную реализацию, если хотите. Тот факт, что ваш абстрактный базовый класс выполняет проверку типов в коде, достаточен, чтобы сказать вам, что это неправильная абстракция.

Как и в большинстве вещей в OOD, когда вы находитесь в канавке и хорошо справились со своей объектной моделью, ваш код сообщит вам, что будет дальше. Начните с интерфейса, реализуйте этот интерфейс в нужных вам классах. Если вы обнаружите, что пишете похожий код, извлеките его в абстрактный базовый класс - если важен интерфейс, абстрактный базовый класс - просто помощник, и их может быть несколько.

Это довольно сложно ответить, не зная остальной части приложения.

Предполагая, что вы используете какую-то модель DI и разработали свой код так, чтобы он был максимально расширяемым (чтобы вы могли TypeNameMapperлегко добавлять новые ), я бы сказал, да.

Причины для:

• Вы фактически получаете его бесплатно, так как базовый класс реализует то, что interfaceвам не нужно беспокоиться об этом в любых дочерних реализациях
• Большинство IoC-фреймворков и библиотек Mocking ожидают interfaces. Хотя многие из них работают с абстрактными классами, это не всегда само собой разумеющееся, и я твердо верю, что, по возможности, буду следовать тем же путем, что и остальные 99% пользователей библиотеки.

Причины против:

• Строго говоря (как вы указали) вам НЕ ДЕЙСТВИТЕЛЬНО нужно
• Если class/ interfaceизменяется, есть немного дополнительных накладных расходов

Учитывая все это, я бы сказал, что вы должны создать interface. Причины этого весьма незначительны, но, хотя можно использовать тезисы при моделировании и IoC, часто с интерфейсами гораздо проще. В конечном счете, я бы не стал критиковать кодекс коллег, если бы они пошли другим путем.