Сравнение интерфейсов и абстрактных классов

1. Коротко о классических различиях

Если кто-то говорит: «Интерфейс — это просто набор сигнатур», спросите: «А на какой версии C# вы пишете?» Начиная с C# 8 и новее интерфейсы стали гораздо мощнее. Пора сравнить их с абстрактными классами — не только по классическим свойствам, но и с учетом всех новых фишек платформы .NET.

Если вернуться на несколько лет назад — к C# 7, — всё было просто. Абстрактный класс может определять поля и частично реализованные методы, интерфейс — только сигнатуры (методов, свойств, событий, индексаторов).
Наследование абстрактного класса реализуется через отношение "является" (Is-a), интерфейсы реализуют множественное наследование поведения ("умеет", can-do).

Как видите, раньше абстрактные классы были настоящими "старшими братьями" интерфейсов — мощнее и гибче. Но всё меняется!

2. Интерфейсы с реализацией по умолчанию

С выходом C# 8 (и уж тем более в C# 14 и .NET 9) интерфейсы получили новую суперспособность — методы с реализацией по умолчанию, которые называют "Default Interface Methods" (DIM).

Как это выглядит?

public interface IAnimal
{
    void SayHello();

    // Метод с реализацией по умолчанию!
    void Walk()
    {
        Console.WriteLine("Я иду...");
    }
}

Вау! Вдруг оказалось, что интерфейс теперь может содержать реализацию метода. Причём не одну, а сколько душе угодно. Но есть нюанс: такие методы обязательно должны быть явно объявлены с телом, а всё остальное (поля, приватные методы, конструкторы) — по-прежнему нельзя.

3. Современные возможности интерфейсов

Новые фишки, о которых стоит знать современному .NET-разработчику:

• Методы с реализацией по умолчанию.
• Приватные методы внутри интерфейса (только для вспомогательных целей, доступны только другим методам этого же интерфейса).
• Статические методы (начиная с C# 8).
• Свойства с реализацией по умолчанию.
• Статические поля (начиная с C# 14 — "static interface members").
• Абстрактные статические члены ("abstract static members" — да, теперь интерфейс может требовать у реализации определённые статические методы!).

Пример полного современного интерфейса:

public interface ILogger
{
    static int LoggerCount { get; set; } // C# 14

    void Log(string message); // Сигнатура (контракт)

    // Default implementation
    void LogWarning(string warning)
    {
        Log("[WARNING]: " + warning);
    }
    
    // Приватный вспомогательный метод в интерфейсе (C# 8+)
    private void FormatAndLog(string level, string msg)
    {
        Log($"{level}: {msg}");
    }

    // Static метод в интерфейсе (C# 8+)
    static void PrintLoggerInfo()
    {
        Console.WriteLine("Интерфейс ILogger — ваш лучший помощник!");
    }
}

Вы только представьте — раньше такое было просто невозможно, это как если бы кто-то позволил кошке работать охранником сервера.

4. Абстрактные классы: что нового?

Абстрактные классы... как бы это сказать... не сильно эволюционировали за последнее десятилетие. Они по-прежнему могут содержать:

• Поля (в том числе приватные, защищённые и статические).
• Реализованные и абстрактные методы.
• Конструкторы (да, можно создавать абстрактные классы с логикой инициализации).
• Свойства, события, индексаторы.
• Статические и инстанс-члены.

Пример абстрактного класса:

public abstract class Animal
{
    public string Name { get; set; }

    public abstract void Speak();

    public virtual void Walk()
    {
        Console.WriteLine($"{Name} шагает на лапках!");
    }

    protected void Eat()
    {
        Console.WriteLine($"{Name} ест корм.");
    }
}

Абстрактный класс по-прежнему остаётся отличным местом для хранения общей логики, состояний и поведения для иерархии классов.

5. Современное сравнение: таблица с учётом новых возможностей

* — В интерфейсах статические поля обычно используются в особых случаях, и это совсем свежая фишка языка.

6. Где использовать интерфейс, а где — абстрактный класс: современные рекомендации

Интерфейсы (а теперь и с реализацией по умолчанию) — инструмент для создания контрактов между компонентами. Их ключевая черта: множественность. Ваш класс может реализовывать хоть десять разных интерфейсов, что делает его универсальным солдатом.

Абстрактный класс остается вашим выбором, если:

• Требуется общее состояние (поля), логика и поведение, которые наследуют другие классы.
• Необходима стандартная, но переопределяемая логика (используйте virtual).
• Вы хотите централизовать инициализацию через конструктор.

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

.                     ┌────────────────────────┐
                      │      Интерфейс         │
                      │  (контракт: что умеет) │
                      └─────────┬──────────────┘
                                │
                 ┌──────────────┼──────────────┐
                 │              │              │
           Реализация 1   Реализация 2 ...  Реализация N
             MyLogger     CloudLogger     FileLogger
    
        (можно комбинировать с наследованием абстрактного класса)

7. Сценарии — когда что выигрывает

Множественная реализация:
Допустим, у вас есть интерфейс IDrivable и абстрактный класс Vehicle. Теперь класс Car может наследовать базу — Vehicle — и в то же время реализовывать несколько интерфейсов (IDrivable, IRepairable, IInsurable). Если бы у вас был абстрактный класс Repairable, пришлось бы выбирать — либо Vehicle, либо Repairable! Интерфейсы тут явно выигрывают.

Общая логика и состояние:
Допустим, у всего "автотранспорта" есть поле "номер". Это должно быть полем абстрактного класса. В интерфейсе поля (во всяком случае, кроме статических) нельзя.

Эволюция API:
Одна из революционных историй с Default Interface Methods — теперь интерфейсы можно эволюционировать без риска сломать существующих потребителей.
Например, добавили в интерфейс новый метод с реализацией по умолчанию — всё работает, все старые имплементации интерфейса не упали! Раньше это было больно (или, если забыть про боль, всё равно невозможно).

8. Примеры на практике

В нашем учебном приложении постепенно появляется логгирование. Давайте создадим свой интерфейс ILogger с реализацией по умолчанию:

public interface ILogger
{
    void Log(string message);

    // Реализация по умолчанию доступна всем реализациям интерфейса!
    void LogInfo(string info)
    {
        Log("[INFO] " + info);
    }

    // Статический метод интерфейса
    static void PrintHelp()
    {
        Console.WriteLine("Используйте ILogger для логирования событий");
    }
}

public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

// Где-то в коде:
ILogger logger = new ConsoleLogger();
logger.LogInfo("Система запущена!"); // работает благодаря default-реализации

// Вызов статического метода интерфейса
ILogger.PrintHelp();

Если бы мы добавили новый метод с реализацией по умолчанию в интерфейс, все существующие реализации (например, ConsoleLogger) автоматически получили бы этот новый метод — никакой паники и поломки кода.

9. Ошибки и нюансы: практика и грабли

Стоит знать, что не всё так радужно, как может показаться на первый взгляд. Например, если ваш интерфейс содержит default-реализацию, но потребитель обращается к объекту через тип класса, а не через тип интерфейса, default-реализация доступна только через интерфейс.

ConsoleLogger log = new ConsoleLogger();
log.LogInfo("Hello"); // Не скомпилируется: LogInfo не определён в классе!

ILogger log2 = log;
log2.LogInfo("Hello"); // Всё хорошо!

Это похоже на частный случай явной реализации интерфейса. Иногда такое поведение удобно для сокрытия "лишнего" API, иногда — неожиданно для новичков.

2

Задача

C# SELF, 24 уровень, 2 лекция

Недоступна

Реализация интерфейса с использованием методов с реализацией по умолчанию

Реализация интерфейса с использованием методов с реализацией по умолчанию

Открыть

2

Задача

C# SELF, 24 уровень, 2 лекция

Недоступна

Использование статического метода в интерфейсе

Использование статического метода в интерфейсе

Открыть