Когда принцип разделения интерфейса не применяется?SOA?

Question

Я ищу примеры сценариев, в которых принцип разделения интерфейса (из SOLID) не должен использоваться.

Единственный, что я видел упомянутый (но не объясненный), это случай интерфейса для сервиса в контексте SOA. Но почему? Это потому, что в этом случае интерфейс должен быть толстым по дизайну? По указанию SOA?

Существуют ли другие ситуации, когда провайдер не является хорошей идеей?

Заранее спасибо.

Answer 1

SOLID - это хороший принцип, моя идея в том, что вы не должны применять их, когда думаете, что вы чрезмерно проектируете!Например, я применяю ISP в основном на классах моего сервисного уровня, на бизнес-уровне, я изменю свои классы, потому что это изменение в бизнесе, я не буду создавать новую реализацию (и я нарушаю принцип Open / Close,но мне все равно, потому что это меняет бизнес!).

РЕДАКТИРОВАТЬ: я также применяю ISP в моем уровне данных, поэтому я применяю ISP в основном для всех вопросов ввода / вывода (xml, sql, email...).

Если вы будете применять ISP везде, у вас будут сотни интерфейсов, и это может стать кошмаром для отладки / инициализации.

Answer 2

Хорошее время, чтобы не применять ISP, это когда вы начали с небольших интерфейсов и со временем вы узнали больше о домене и обнаружили, что некоторые из них связаны.Те, которые связаны, могут быть реорганизованы в меньшее количество интерфейсов, потому что вы можете увидеть из реального мира ( Правило трех ), что они принадлежат друг другу - их поведение связано;они используются в одних и тех же контекстах и ​​сценариях.Именно с этим опытом связанных интерфейсов может быть принято обоснованное решение, чтобы свернуть их.Тогда ваш домен станет богаче, и вы не будете СУХИМ слишком рано .

Проблема с приведенным выше советом заключается в том, что вы фактически применяете ISP , начиная с малого и переходя к большему позже.Возможно, вопрос спорный?: Р

Answer 3

Я не использую интерфейсы, если у меня не более 1 реализации. Когда придет время, я применяю принцип. Вся идея об интерфейсах состоит в том, чтобы иметь несколько реализаций. Удачи.