Для чего нужны интерфейсы?

В чем сила интерфейсов? Сила интерфейсов в правде слабости системы типов!

Принято считать, что интерфейсы предназначены для моделирования абстракций и обеспечения слабой связанности (loose coupling). Звучит умно, но что это значит?

Что дают интерфейсы?

Наследование моделирует семейство объектов с общим поведением. Интерфейс и абстрактный класс определяет «протокол» этого семейства, а наследники определяют конкретную реализацию. Разные виды предусловий можно спрятать за интерфейсом IPrecondition, разные виды стратегий сортировки – за ISorter, разные виды импортеров/экспортеров – за Importer/Exporter.

Наличие интерфейсов/абстрактных классов позволяет думать о задаче более абстрактно, не вдаваясь в подробности, какая конкретная разновидность используется. Абстрактность интерфейсов позволяет сосредоточиться на главном, игнорируя второстепенные детали. Отсюда вытекает распространенное убеждение, что интерфейс моделируют абстракцию.

Существуют разные уровни абстрагирования или игнорирования деталей. Домашний кондиционер является разновидностью «устройства управления климатом», но конкретный кондиционер, установленный лично в вашем доме тоже является абстракцией – он прячет от вас свои детали реализации.

Конкретный класс «абстрактен» - его поведение определяется его открытым интерфейсом, а детали реализации скрыты. Будет ли класс реализовывать интерфейс или нет, определяется не требованием «абстрактности», а моделью. Если в вашем «мире» нужно смотреть на конкретный экземпляр кондиционера через призму охладительным приборов, то интерфейс нужен, в противном случае – нет.

Когда класс должен реализовывать интерфейс?

1. Класс реализует стратегию или является частью семейства объектов: IRepository, IFormatter, IPrecondition.

2. Класс реализует ролевой интерфейс (следствие ISP): ICloneable, IComparable etc.

3. Класс реализует интерфейс, требуемый для связи с другими классами. Класс является адаптером; необходимость интерфейса обусловлено принципом DIP.

4. Класс реализует интерфейс, поскольку его реализация завязана на внешнее окружение. Обеспечивает тестируемость клиентов данного класса. Это не должно быть единственной причиной.

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

Аргументы класса говорят о том, что на данном уровне нельзя принять некоторое решение самостоятельно, и класс перекладывает его на вызывающий код. Наличие аргументов – это компромисс между простотой и гибкостью. Класс без аргументов/зависимостей прост в использовании, но у разных клиентов могут быть разные потребности, которые решаются «конфигурированием» класса с помощью аргументов.

Чем сложнее аргументы, тем сложнее пользоваться классом. Проще всего, когда класс завязан на примитивные типы. Сложнее, когда он завязан на пользовательские неизменяемые типы. Еще сложнее, когда он завязан на интерфейсы или абстрактные классы. Последнее значит, что класс не знает, что ему понадобится и предлагает решить эту проблему клиентам.

Причины, когда класс должен требовать интерфейсы в аргументах конструктора:

• Класс работает с семейством типов. «Семейство типов» уже существует и определяется требованиями текущей модели, а не воображением разработчика.
• Следствие DIP. Класс хочет общаться с объектом другого уровня. Он сам определяет интерфейс и требует его реализацию. Можно рассматривать, как особую форму паттерна Наблюдателя.
• Для обеспечения тестируемости. Полезно, только если реализация «абстракции» завязана на внешнее окружение. Даже в этом случае можно обойтись Шаблонным Методом: выделить общение с внешним ресурсом не во внешнюю зависимость, а в виртуальный метод и переопределить его в тесте.

Выделять интерфейсы «на всякий случай» - не нужно! Если это библиотечный код, то интерфейсы там полное зло: любое их изменение – ломает всех клиентов. А если это продакшн код, то он все равно будет меняться, и наличие лишних интерфейсов лишь сделает этот процесс более сложным.