Принцип разделения интерфейса (Interface segregation principle)

В области разработки программного обеспечения принцип разделения интерфейса (ISP) гласит, что ни один клиент не должен быть вынужден зависеть от методов, которые он не использует. ISP разбивает очень большие интерфейсы на более мелкие и более специфичные, чтобы клиенты могли знать только о методах, которые им интересны. Такие сокращенные интерфейсы также называются ролевыми интерфейсами. ISP предназначен для поддержания развязанности (decoupled) системы и, таким образом, упрощения ее рефакторинга, изменения и повторного развертывания. ISP - это один из пяти SOLID принципов объектно-ориентированного проектирования, аналогичный принципу высокой связности (High Cohesion Principle) GRASP.

Важность в объектно-ориентированном дизайне

В объектно-ориентированном дизайне интерфейсы предоставляют уровни абстракции, которые упрощают код и создают барьер, предотвращающий связь с зависимостями.

По мнению многих экспертов по программному обеспечению, подписавших Манифест программного мастерства, написание хорошо продуманного и самообъяснимого программного обеспечения почти так же важно, как написание рабочего программного обеспечения. Использование интерфейсов для дальнейшего описания намерений программного обеспечения часто является хорошей идеей.

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

Происхождение

ISP был впервые использован и сформулирован Робертом К. Мартином при консультировании Xerox. Компания Xerox создала новую систему печати, которая могла выполнять различные задачи, такие как сшивание и отправка факсов. Программное обеспечение для этой системы было создано с нуля. По мере роста программного обеспечения внесение изменений становилось все более и более трудным, поэтому даже малейшее изменение занимало цикл перераспределения в течение часа, что делало разработку практически невозможной.

Проблема дизайна состояла в том, что один класс Job использовался почти всеми задачами. Всякий раз, когда нужно было выполнить задание на печать или сшивание, был сделан вызов в класс Job. В результате появился "толстый" класс с множеством методов, специфичных для различных клиентов. Из-за этого дизайна основная работа знала бы обо всех методах печати, хотя они были бесполезны.

В предложенном Мартином решении использовалось то, что сегодня называется принципом разделения интерфейсов. Применительно к программному обеспечению Xerox интерфейсный уровень между классом Job и его клиентами был добавлен с использованием принципа инверсии зависимостей. Вместо того, чтобы иметь один большой класс Job, был создан интерфейс Staple Job или Print Job, который будет использоваться классами Staple или Print, соответственно, вызывая методы класса Job. Поэтому для каждого типа задания был создан один интерфейс, который был реализован классом Job.

Типичное нарушение

Типичное нарушение принципа разделения интерфейса приведено в статье "Гибкая разработка программного обеспечения: принципы, шаблоны и практики" в "примере транзакции ATM", а также в статье, написанной Робертом С. Мартином специально об ISP. В этом примере обсуждается пользовательский интерфейс для банкомата, который обрабатывает все запросы, такие как запрос на депозит или запрос на снятие средств, и как этот интерфейс необходимо разделить на отдельные и более конкретные интерфейсы.


Читайте также:

Комментарии

Анонимный написал(а)…
Я ухватился за возможность приобрести недвижимость в аренду на 4-е число выходных. Г-н Ли быстро ответил, и, поскольку я впервые получил ссуду на покупку арендуемой собственности, он смог помочь мне пройти через процесс ссуды. Это был отличный опыт работы с хорошим и любезным кредитором г-ном Ли. Я надеюсь, что очень хорошо знаю, если вы ищете ссуду для покупки недвижимости или финансирования бизнеса, тогда г-н Ли сможет помочь вам с таким процессом, здесь его данные WhatsApp + 1-989-394-3740. / 247officedept@gmail.com

Популярные сообщения из этого блога

Язык поисковых запросов в Graylog

Нормальные формы, пример нормализации в базе данных

Хэш-таблица: разрешение коллизий