В области разработки программного обеспечения принцип разделения интерфейсов ( ISP ) гласит, что никакой код не должен зависеть от методов, которые он не использует. [1] ISP разделяет интерфейсы , которые очень большие, на более мелкие и более конкретные, так что клиентам нужно будет знать только о тех методах, которые им интересны. Такие урезанные интерфейсы также называются ролевыми интерфейсами . [2] ISP предназначен для того, чтобы система оставалась разъединенной и, таким образом, ее было легче рефакторить, изменять и повторно развертывать. ISP является одним из пяти принципов SOLID объектно-ориентированного проектирования, похожим на принцип высокой связности GRASP . [3] Помимо объектно-ориентированного проектирования, ISP также является ключевым принципом проектирования распределенных систем в целом и одним из шести принципов IDEALS для проектирования микросервисов . [4]
В объектно-ориентированном проектировании интерфейсы предоставляют слои абстракции, которые упрощают код и создают барьер, препятствующий связыванию с зависимостями . Система может стать настолько связанной на нескольких уровнях, что больше невозможно будет внести изменение в одном месте без необходимости внесения множества дополнительных изменений. [1] Использование интерфейса или абстрактного класса может предотвратить этот побочный эффект.
ISP был впервые использован и сформулирован Робертом К. Мартином [5] во время консультирования Xerox . Xerox создал новую систему принтеров, которая могла выполнять различные задачи, такие как сшивание и отправка факсов. Программное обеспечение для этой системы было создано с нуля. По мере развития программного обеспечения внесение изменений становилось все более и более сложным, так что даже самое незначительное изменение требовало цикла повторного развертывания в течение часа, что делало разработку практически невозможной.
Проблема дизайна заключалась в том, что практически все задачи использовали один класс Job. Всякий раз, когда требовалось выполнить задание печати или сшивания, вызывался класс Job. Это приводило к «толстому» классу с множеством методов, специфичных для различных клиентов. Благодаря такому дизайну задание сшивания знало обо всех методах задания печати, даже если они не использовались.
Решение, предложенное Мартином, использовало то, что сегодня называется принципом разделения интерфейсов. Применительно к программному обеспечению Xerox был добавлен интерфейсный слой между классом Job и его клиентами с использованием принципа инверсии зависимостей . Вместо одного большого класса Job был создан интерфейс Staple Job или интерфейс Print Job, который использовался классами Staple или Print, соответственно, вызывая методы класса Job. Таким образом, для каждого типа задания был создан один интерфейс, который был полностью реализован классом Job.
Типичное нарушение принципа разделения интерфейса приведено в книге Agile Software Development: Principles, Patterns, and Practices [1] в разделе «Пример транзакции через банкомат» и в статье, также написанной Робертом К. Мартином специально об интернет-провайдере. [6] В этом примере обсуждается пользовательский интерфейс банкомата, который обрабатывает все запросы, такие как запросы на внесение депозита или запросы на снятие средств, и то, как этот интерфейс должен быть разделен на отдельные и более конкретные интерфейсы.