Когда принцип разделения интерфейса не применяется? SOA?
Я ищу примеры сценариев, в которых принцип разделения интерфейса (из SOLID) не должен использоваться.
Единственное, что я видел упомянутым (но не объясненным), это случай интерфейса для сервиса в контексте SOA. Но почему? Это потому, что в этом случае интерфейс должен быть толстым по дизайну? По указу SOA?
Есть ли другие ситуации, когда провайдер не является хорошей идеей?
Заранее спасибо.
3 ответа
SOLID - это хороший принцип, моя идея в том, что вы не должны применять их, когда думаете, что вы чрезмерно инженерны! Например, я применяю ISP в основном на классах моего сервисного уровня, на бизнес-уровне я буду менять свои классы, потому что это изменение в бизнесе, я не буду создавать новую реализацию (и я нарушаю принцип Open/Close, но мне все равно, потому что это бизнес меняется!).
РЕДАКТИРОВАТЬ: я также применяю ISP в моем уровне данных, поэтому я применяю ISP в основном для всех вопросов ввода / вывода (xml, sql, email ...).
Если вы будете применять ISP везде, вы получите сотни интерфейсов, и это может стать кошмаром для отладки / инициализации.
Хорошее время, чтобы не применять ISP, - это когда вы начинаете с небольших интерфейсов и со временем вы узнаете больше о домене и обнаружите, что некоторые из них связаны. Те, которые связаны, могут быть реорганизованы в меньшее количество интерфейсов, потому что из реального мира ( Правило Трех) вы можете видеть, что они принадлежат друг другу - их поведение взаимосвязано; они используются в одних и тех же контекстах и сценариях. Именно с этим опытом связанных интерфейсов может быть принято обоснованное решение, чтобы свернуть их. Тогда ваш домен станет богаче, и вы не будете СУХОЙ слишком рано.
Проблема с приведенным выше советом заключается в том, что вы на самом деле применяете ISP, начиная с малого и переходя к большему позже. Возможно, вопрос спорный?:п
Я не использую интерфейсы, если у меня не более 1 реализации. Когда придет время, я применяю принцип. Вся идея об интерфейсах состоит в том, чтобы иметь несколько реализаций. Удачи.