SOLID «I»: Принцип разделения интерфейса
Суть принципа разделения интерфейса – в бизнес-логике и клиентском общении. Во всех модульных приложениях должен быть интерфейс, которым может воспользоваться клиент. Это может быть классический объект, реализуемый в шаблонах проектирования вроде Facades. Не важно, применяется то или иное решение. Суть всегда остается той же: объяснить клиентскому коду как правильно использовать модуль. Эти интерфейсы могут находиться между различными модулями в одном приложении или проекте, или между одним проектом в качестве сторонней библиотеки, служащей для подачи еще одного проекта.
Хороший способ на старте определить, что именно мы хотим реализовать в нашем модуле. Подобное начало может привести к одной из реализаций:
- большой класс Car или Bus реализует методы интерфейса Vehicle. Одни размеры таких классов советуют избегать их любой ценой;
- маленькие классы вроде LightsControl, SpeedControl или RadioCD реализуют весь интерфейс, но делают что-то полезное только для реализуемых ими частей;
Очевидно, что ни одно из этих решений не подходит для реализации нашей бизнес-логики.
Мы могли бы попробовать еще один подход: разбить интерфейс на куски, каждый из которых займется своей реализацией. Для маленьких классов – идеально. Объекты, реализующие интерфейсы, будут использовать другой тип транспорта, например, машину (car) на картинке выше.
Но это может фундаментально изменить наше восприятие архитектуры. Вместо реализации Car становится клиентом. А мы хотим дать возможность клиенту использовать весь модуль.
Предположим, что проблема реализации уже решена, а бизнес-логика – стабильна. Прежде всего, нужно обеспечить единый интерфейс со всеми реализациями и пусть клиенты BusStation, HighWay, Driver используют все, что угодно из реализации. Это перекладывает ответственность за поведение на клиентов (подобный метод часто применялся в старых приложениях). Принцип разделения интерфейса утверждает, что ни один клиент не должен зависеть от неиспользуемых методов.
Но есть одна проблема: все клиенты зависят от всех методов. Разве BusStation должен зависеть от радиостанции, которую выбрал водитель, или от фар автобуса? Нет. Но что, если так оно и будет? Нужно вспомнить принцип единой обязанности. Если BusStation зависит от многих реализаций (и даже не используемых), то он может потребовать изменений, если изменится одна из реализаций. Такого быть не должно.
Интерфейсы относятся к клиентам, а не к реализациям, поэтому и создавать их нужно в лучших отношениях с клиентом. Мы должны разбить интерфейсы на кусочки так, чтобы они лучше работали с клиентами.
Конечно, могут появиться дубляжи, но помните, что интерфейсы – это простые определения имен функций и логика в них не реализуется, а значит, и проблем с дублированием не будет.
Здесь есть преимущество перед клиентами, которые зависят только от того, что им нужно и что они используют сами по себе. В некоторых случаях клиенты могут использовать и нуждаться в нескольких интерфейсах, и это совершенно нормально, пока они используют все методы всех интерфейсов, от которых зависят.
Еще один приятный момент заключается в том, что в нашей бизнес-логике один класс может реализовать несколько интерфейсов, если ему это понадобится. Так что мы можем обеспечить единую реализацию для всех общих методов между интерфейсами. Интерфейсы также заставляют нас думать о нашем коде больше с точки зрения клиента, что, в свою очередь, приводит нас к уже более легкому тестированию. Так что мы не только сделали наш код лучше для наших клиентов, мы также сделали его проще для себя, чтобы легче понимать, тестировать и реализовывать.
Резюме
Принцип подстановки Барбары Лисков демонстрирует, почему реальные объекты нельзя сопоставлять один к одному с объектами программирования, и учит писать код таким образом, чтоб подтипы хорошо уживались с базовыми типами. Принцип подстановки дополняет другие принципы SOLID и проще интерпретируется в их контексте.
Принцип разделения интерфейса учит нас уважать клиентов еще сильнее, чем мы это делали раньше. Внимание к их потребностям может сделать наш код намного лучше, а нашу работу – проще и интереснее.
Источник: code.tutsplus.com
