Что хотят услышать интервьюеры:

Разные реализации одного интерфейса нужны, чтобы отделить контракт от конкретного поведения и не привязывать код к одной реализации. Это упрощает замену компонентов, тестирование и расширение системы без переписывания потребителей. Интерфейс задает, что умеет объект, а реализация — как именно это делается.

Определение:

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

Пример использования:

Например, есть интерфейс PaymentProcessor, а разные реализации обрабатывают оплату картой, через PayPal или банковским переводом.

interface PaymentProcessor {
    void pay(int amount);
}

class CardPayment implements PaymentProcessor {
    public void pay(int amount) {
        System.out.println("Оплата картой: " + amount);
    }
}

class PaypalPayment implements PaymentProcessor {
    public void pay(int amount) {
        System.out.println("Оплата через PayPal: " + amount);
    }
}

class OrderService {
    private final PaymentProcessor processor;

    OrderService(PaymentProcessor processor) {
        this.processor = processor;
    }

    void checkout() {
        processor.pay(1000);
    }
}

Пояснение кода:

В этом примере OrderService зависит не от конкретного способа оплаты, а от интерфейса PaymentProcessor. Если нужно поменять способ оплаты, достаточно подставить другой объект, например PaypalPayment вместо CardPayment. Это не требует изменений в OrderService.

Шаги работы:

PaymentProcessor задает общий метод pay.
CardPayment и PaypalPayment реализуют этот метод по-разному.
OrderService принимает любой объект, который соответствует интерфейсу.
При вызове checkout() используется конкретная реализация, переданная в сервис.

Ключевые моменты:

Интерфейс фиксирует контракт, а не реализацию.
Несколько реализаций одного интерфейса повышают гибкость системы.
Упрощается подмена компонентов без изменения клиентского кода.
Проще писать тесты: вместо реальной реализации можно подставить mock или stub.
Это основа принципа программирования на уровне абстракций, а не конкретных классов.

В чем заключается необходимость предоставления различных реализаций одного интерфейса?