В чем разница между SRP и ISP в SOLID? (Принцип единой ответственности и принцип разделения интерфейса)

SRP сообщает нам, что у вас должна быть только одна ответственность в модуле.

Интернет-провайдер говорит нам, что вы не должны быть вынуждены сталкиваться с тем, что вам действительно нужно. Если вы хотите использовать метод print() из интерфейса I, вам не нужно создавать для этого класс SwimmingPool или DriveThru.

Если говорить более конкретно и сразу перейти к делу, это разные взгляды на одну и ту же идею - SRP больше ориентирован на точку зрения дизайнера, в то время как ISP больше ориентирован на точку зрения на стороне клиента. . Так что вы в основном правы.

Все это пришло из

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

so

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

@ http://en.wikipedia.org/wiki/Interface_segregation_principle#Origin

SRP касается того, что делает модуль и как это делается, запрещая любое сочетание уровней абстракции. По сути, до тех пор, пока компонент может быть подробно определен одним предложением, это не нарушит SRP.

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

Примером кода, который сохраняет дух или SRP, но может нарушить работу ISP, является паттерн Фасад. У него единственная ответственность: «обеспечение упрощенного доступа к более крупной подсистеме», но если лежащая в основе подсистема должна раскрыть совершенно разные взгляды, это действительно нарушит работу ISP.

Тем не менее, обычно, когда фрагмент кода нарушает принцип SOLID, он часто ломает всю его часть. Конкретные примеры, которые нарушают определенный принцип, сохраняя при этом остальное, в дикой природе редки.

Роберт Мартин написал следующее в Твиттере 16 мая 2018 г.

ISP можно рассматривать как аналог SRP для интерфейсов; но это нечто большее. Интернет-провайдер обобщает: «Не полагайтесь на большее, чем вам нужно». SRP обобщает так: «Собирайте воедино вещи, которые меняются по одним и тем же причинам и в одно и то же время».

Представьте себе класс стека с push и pop. Представьте себе клиента, который только подталкивает. Если этот клиент зависит от интерфейса стека, это зависит от pop, в котором он не нуждается. SRP не отделяет push от pop; Провайдер бы.

SRP и ISP в конечном итоге сводятся к одному и тому же. Реализация любого из них требует разделения классов или интерфейсов.

Однако есть отличия по другим направлениям.

1. Нарушение SRP может иметь далеко идущие последствия для всей структуры проекта, приводя к плохой ремонтопригодности, повторному использованию и, конечно же, к низкой когезии и связанности.
2. SRP влияет как на поведенческие, так и на структурные компоненты структуры объекта.
   
3. Перепроектирование с нарушением SRP требует более глубокого анализа, требует целостного рассмотрения различных компонентов дизайна.

Нарушение ISP в основном связано с плохой читабельностью (и, в некоторой степени, низкой связностью). Но влияние на обслуживание и повторное использование кода гораздо менее зловещее, чем у SRP.

Более того, рефакторинг кода для соответствия ISP, кажется, всего лишь структурным изменением.

См. Также мой блог для SRP и Интернет-провайдер