Программируйте на уровне интерфейса
Программируйте на уровне интерфейса, а не на уровне реализации. Код должен зависеть от абстракций, а не конкретных классов.
Гибкость архитектуры выражает в том, чтобы её можно было расширять, не ломая существующий код. Для примера вернёмся к классу котов. Класс Кот, который ест только сардельки, будет менее гибким, чем тот, что может есть любую еду. Но при этом, последнего можно будет кормить и сардельками, ведь они являются едой.
Когда вам нужно наладить взаимодействие между двумя объектами разных классов, самое простое, что вы можете сделать, это сделать один класс зависимым от другого. Что говорить, зачастую, я и сам с этого начинаю. Но есть и другой, более гибкий, способ.
- Определите, что именно нужно одному объекту от другого, какие методы он вызывает.
- Затем, опишите эти методы в отдельном интерфейсе.
- Сделайте так, чтобы класс-зависимость следовал этому интерфейс. Скорей всего, нужно будет только добавить этот интерфейс в описание класса.
- Теперь вы можете и сделать второй класс зависимым от интерфейса, а не конкретного класса.
До и после извлечения интерфейса.
Код справа более гибкий, чем тот, что слева, но и более сложный.
Проделав всё это вы, скорей всего, не получите немедленной выгоды. Но зато в будущем, вы сможете использовать альтернативные реализации классов, не изменяя использующий их код.
Пример
Давайте рассмотрим ещё один пример, где работа на уровне интерфейса оказывается выигрышней привязки к конкретным классам. Представьте, что вы делаете симулятор софтверной компании. У вас есть различные классы работников, которые делают ту или иную работу внутри компании.
ДО: классы жёстко связаны.
Вначале класс компании жёстко привязан к конкретным классам работников. Несмотря на то, что каждый тип работников делает разную работу, мы можем свести их методы работы к одному виду, выделив для всех классов общий интерфейс.
Сделав это, мы сможем применить полиморфизм в классе компании, трактуя всех работников единообразно через интерфейс Employee.
ЛУЧШЕ: полиморфизм помог упросить код, но основной код компании всё ещё зависит от конкретных классов сотрудников.
Тем не менее, класс компании всё ещё остаётся жёстко привязанным к конкретным классам работников. Это не очень хорошо, особенно, если предположить, что нам понадобится реализовать несколько видов компаний. Все эти компании будут отличаться тем, какие конкретно работники в них нужны.
Мы можем сделать метод получения сотрудников в базовом классе компании абстрактным. Конкретные компании должны будут сами позаботиться о создании объектов сотрудников. А значит — каждый тип компаний сможет иметь собственный набор сотрудников.
ПОСЛЕ: основной код класса компании стал независимым от классов сотрудников. Конкретных сотрудников создают конкретные классы компаний.
После этого изменения, код класса компании стал окончательно независимым от конкретных классов. Теперь мы можем добавлять в программу новые виды работников и компаний, не внося изменений в основной код базового класса компаний.
Кстати, вы только что увидели пример одного из паттернов, а именно — Фабричного метода. Мы ещё вернёмся к нему в дальнейшем.
