Что такое интерфейс в контексте ООП и какие функции он выполняет как контракт?

Интерфейс в ООП — это абстрактный тип, который определяет набор методов без их реализации. Он работает как контракт: любой класс, который реализует интерфейс, обязуется предоставить код для всех методов, объявленных в нём. Это позволяет разным классам гарантировать одинаковое поведение, не привязываясь к конкретной реализации.

Основные функции интерфейса как контракта:

• Декомпозиция: интерфейс отделяет «что делает объект» от «как он это делает». Например, интерфейс PaymentProcessor может объявлять метод pay(amount), а классы CreditCardProcessor и PayPalProcessor реализуют его по-своему.
• Полиморфизм: код, работающий через интерфейс, может использовать любую реализацию. В Java это выглядит так: List<String> list = new ArrayList<>(); — мы работаем через интерфейс List, а не через конкретный класс.
• Тестируемость: интерфейсы позволяют подменять реальные зависимости на моки. Вместо базы данных можно передать UserRepository с заглушкой, которая возвращает тестовые данные.
• Слабая связанность: модули зависят от абстракций, а не от конкретных классов. Это упрощает замену компонентов без изменения вызывающего кода.

Пример на Java:

public interface Drawable {
    void draw();
}

public class Circle implements Drawable {
    @Override
    public void draw() {
        System.out.println("Рисуем круг");
    }
}

public class Square implements Drawable {
    @Override
    public void draw() {
        System.out.println("Рисуем квадрат");
    }
}

// Использование
Drawable shape = new Circle();
shape.draw(); // Выведет "Рисуем круг"

Важно: интерфейс не содержит состояния (полей) и не может быть инстанциирован. В Java 8+ появились default-методы, но это исключение, а не правило. В языках вроде Go интерфейсы могут быть неявными — класс реализует интерфейс, если у него есть все нужные методы, без явного implements.

На собеседовании стоит упомянуть, что интерфейсы — это инструмент для реализации принципа «программирование на уровне интерфейсов, а не реализаций» (из SOLID). Без них код быстро превращается в кашу из жёстких зависимостей.