Что такое интерфейс в объектно-ориентированном программировании (ООП)?

Question

Что такое интерфейс в объектно-ориентированном программировании (ООП)?

Тип вопроса: ООП Вероятность: 32% Категория: C# Разработчик

Ответ

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

Ключевая цель: Декомпозиция системы, достижение слабой связанности (loose coupling) и полиморфизма.

Пример в C#:

// Контракт для логирования
public interface ILogger
{
    void Log(string message, LogLevel level);
    bool IsEnabled(LogLevel level);
}

// Конкретная реализация для консоли
public class ConsoleLogger : ILogger
{
    public void Log(string message, LogLevel level)
    {
        if (IsEnabled(level))
        {
            Console.WriteLine($"[{level}] {DateTime.UtcNow}: {message}");
        }
    }

    public bool IsEnabled(LogLevel level) => level >= LogLevel.Information;
}

// Конкретная реализация для файла
public class FileLogger : ILogger { /* ... */ }

// Использование через интерфейс (полиморфизм)
public class OrderProcessor
{
    private readonly ILogger _logger;
    // Внедрение зависимости через интерфейс
    public OrderProcessor(ILogger logger) => _logger = logger;

    public void ProcessOrder()
    {
        _logger.Log("Начало обработки заказа", LogLevel.Information);
        // ... логика
    }
}

Преимущества:

Полиморфизм: Код OrderProcessor работает с любым ILogger.
Тестируемость: Легко подменить реальный логгер на мок (mock) в юнит-тестах.
Множественное наследование: Класс может реализовать несколько интерфейсов (class MyClass : ILogger, IDisposable).
Разделение ответственности: Четкое определение ролей в архитектуре.

Ответ 18+ 🔞

Давай разберём эту штуку, как будто я тебе на кухне объясняю, водку попивая.

Смотри, интерфейс — это как бумажка от начальства, где написано: «Слушай, чувак, вот тебе список дел. Ты обязан это делать. А КАК ты это будешь делать — мне похуй, твои проблемы».

Вот в коде это выглядит так: есть контракт, абстрактный такой тип. Он говорит классу: «У тебя должны быть вот такие методы, вот такие свойства. Точка». А как внутри эти методы будут работать — интерфейсу абсолютно насрать. Его дело — требовать.

Основная фишка вся в том, чтобы систему разбить на части, которые друг про друга нихрена не знают, но умеют общаться по понятным правилам. Это и есть слабая связанность, или, как я это называю, «чтобы не было пиздеца, когда одну деталь меняешь».

Вот, смотри на примере, сейчас всё станет ясно, как божий день.

// Это наш контракт для логирования. Просто бумажка с требованиями.
public interface ILogger
{
    void Log(string message, LogLevel level); // Должен уметь логировать
    bool IsEnabled(LogLevel level); // Должен уметь отвечать, включён ли лог
}

// А это уже работяга, который контракт выполняет. Пишет всё в консоль.
public class ConsoleLogger : ILogger
{
    public void Log(string message, LogLevel level)
    {
        if (IsEnabled(level)) // Проверяет, а надо ли вообще париться
        {
            Console.WriteLine($"[{level}] {DateTime.UtcNow}: {message}");
        }
    }

    public bool IsEnabled(LogLevel level) => level >= LogLevel.Information; // Вот его реализация, его "как"
}

// А это другой работяга, который в файл пишет. Тот же контракт, но делает по-своему.
public class FileLogger : ILogger { /* ...тут своя магия, но методы те же... */ }

А теперь самое вкусное — использование. Смотри, какая красота:

public class OrderProcessor // Класс, который заказы обрабатывает
{
    private readonly ILogger _logger;
    // Смотри сюда — мы ему в конструктор не конкретного ConsoleLogger суём,
    // а просто говорим: «Дай сюда любого, кто умеет по контракту ILogger работать».
    public OrderProcessor(ILogger logger) => _logger = logger;

    public void ProcessOrder()
    {
        _logger.Log("Начало обработки заказа", LogLevel.Information); // Ему всё равно кто там!
        // ... дальше логика
    }
}

И в чём, собственно, охуенность всего этого?

Полиморфизм, ёпта. Классу OrderProcessor похуй, какой именно логгер придет. Консольный, файловый, или который в облако стучит. Лишь бы методы из контракта были. Подменил — и всё работает, даже не чихнул.
Тестируемость — заебись. В тестах ты можешь воткнуть какую-нибудь заглушку (mock), которая нихрена не логирует, но контракт соблюдает. И проверить, что твой процессор правильно её вызывает. Удобно, как тёплый тапок.
Наследовать можно несколько. Класс один, а контрактов (ILogger, IDisposable, IEnumerable) — овердохуища. В жизни так и бывает: ты и работник, и муж, и дачник. Для каждого своя «роль»-интерфейс.
Разделение ответственности. Архитектура сразу становится чище. Один пишет контракты, другой — реализацию, третий — использует. Все при своих интересах, никто друг другу в тарелку не плюёт.

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