Почему мы должны размещать интерфейсы с классами, которые их используют, а не с теми, которые их реализуют?

Question

Я просматривал статью Роберта К. Мартина, и в одном месте он привел такой пример:

Первое изображение показывает, что между двумя пакетами существует циклическая зависимость.Чтобы удалить эту зависимость, новый интерфейс добавлен во второе изображение.B реализует интерфейс, а Y использует его.И Мартин делает следующее замечание:

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

Answer 1

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

Однако, почему интерфейс изменился бы?

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

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

Кроме того, разработчик "просто" зависит от интерфейса в той мере, в которой он должен обеспечить реализации для каждого из методов в интерфейсе. Но он может предоставить пустые заглушки, по сути, доставляя NOP своим клиентам.

Таким образом, пользователю нужны изменения диска для интерфейса и изменения интерфейса диска для разработчика (ов). Таким образом, пользователь функционально намного ближе к интерфейсу, чем разработчик. Что дает хороший повод объявить интерфейс с пользователем, а не с разработчиком.

Answer 2

Прежде всего следует сказать, что у кошки нет единого способа убрать кожу.

Эта конкретная методология полезна при разделении проекта на несколько проектных групп или создании системы с разделенными подсистемами. Интерфейс служит «контрактом» между двумя подсистемами. Помещая интерфейс на «свою поверхность», потребительская сторона получает лучшую гарантию того, что интерфейс останется неизменным, если исполняющая сторона не свяжется с потребляющей стороной, чтобы запросить такое изменение.

Answer 3

Обычно мы используем интерфейсы в качестве протокола между сервером и клиентом, чтобы клиент знал, какие сервисы доступны, но у этого подхода есть побочный эффект, клиент будет зависеть от сервера и, следовательно, если что-то изменится на стороне сервера что влияет на данный интерфейс, клиент тоже должен измениться. Итак, этот принцип существует среди SOLID принципов, изобретенных Робертом К. Мартином, и это " Принцип обращения зависимостей " или " DIP ", который, как его называют подразумевает, что мы должны инвертировать зависимость между клиентом и сервером, чтобы избежать изменений клиента в будущем. При таком подходе клиент говорит, что ему нужно через интерфейс, и сервер должен реализовать это для удовлетворения своих потребностей, поэтому никаких изменений на стороне сервера заставить нас изменить клиента.

Answer 4

Это проблема разрешения циклических зависимостей между компонентами AB и XY. Ни один не может быть скомпилирован без другого. AB ссылается на XY, а XY ссылается на AB.

Роберт К. Мартин применяет шаблон InversinOfControl для решения этой проблемы

Теперь XY ссылается на ABInterface. ABInterface вообще не нужно знать XY.

Вы правы, это нарушает сплоченность (вы назвали это принципом общего закрытия)

Это также противоречит принципу KeepItSimple. Самое простое решение будет иметь только один монолитный компонент ABXY, который гораздо сложнее поддерживать.

Answer 5

Нет смысла реализовывать интерфейс, пока он не понадобится.YAGNI.