SOLID: ISP

ISP (Interface Segregation Principle) решает проблему жирного интерфейса (fat interface). Понятие fat interface означает интерфейс, в котором содержатся функции, не используемые клиентами интерфейса на 100%. В жирном интерфейсе функции можно разделить на группы, используемые отдельно.

Для наглядности возьму два интерфейса – Water и Fire.

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

Последствия жирного интерфейса: 1. Разработчик вынужден добавить реализацию методов интерфейса Fire в оставшиеся реализации, чтобы удовлетворить требования компилятора, что рискованно созданием неожиданных багов, которые во время компиляции не были обнаружены: клиент ожидает, что методы интерфейса Fire реализованы и вызывает их, доверяя интерфейсу. А на деле методы пустые или ещё хуже – кидают исключение “Не реализовано”. Вариант с исключением был бы странным, ведь разработчик, зная что метод реализовывать в данной реализации нет смысла, сделал интерфейс жирным. 2. Когда разработчик изменяет интерфейс Fire, ему нужно не только отразить эти изменения в реализациях Fire, но также в реализациях Water, даже если в этом нет смысла (п. 1). 3. При тестировании, когда нужно создать fake object, тестировщик вынужден реализовывать два интерфейса, даже если тестирует только Water.

Рецепты: 1. Когда нужно реализовать интерфейсы Water и Fire в одном месте с целью использовать общие данные (кеш, константы), сделайте это. А в месте использования укажите ссылку на один из интерфейсов.

> Пример кода и оригинальная статья в следующем посте

#solid #isp