Являются ли «Инверсия зависимостей» и «Дизайн для интерфейсов» одинаковыми принципами?

Question

Означают ли «Принцип инверсии зависимости» (DIP) и «Принцип проектирования интерфейсов» один и тот же принцип? Если нет, какая разница?

EDIT

Чтобы немного уточнить и сузить контекст: под интерфейсом я подразумеваю программный интерфейс, такой как Java interface или чистый абстрактный базовый класс в C ++. Никакие другие «контракты» не задействованы.

Answer 1

Я просто хотел включить и процитировать Дерека Грира на еще один вопрос, очень похожий на этот , так как, на мой взгляд, он действительно хорошо отвечает на этот вопрос.

‌ "То, на что не ссылается Принцип инверсии зависимостей, - это простая практика абстрагирования зависимостей с помощью интерфейсов (например, MyService → [ILogger ⇐ Logger])."

Хотя это отделяет компонент от конкретной детали реализации зависимости, оно не инвертирует отношения между потребителем и зависимостью (например, [MyService → IMyServiceLogger] ⇐ Logger). "

Answer 2

Инверсия зависимостей гарантирует, что ваши модули более высокого уровня не зависят от модулей более низкого уровня. Таким образом, логика вашего приложения не зависит от вашей бизнес-модели или бизнес-логики. Существует четкое разделение проблем.

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

Расширяем это, если у вас теперь есть три приложения, каждое из которых имеет свои собственные интерфейсы, реализованные бизнес-уровнем, который может изменить ваш бизнес-уровень, и до тех пор, пока они реализуют интерфейсы так, как должны, ваши приложения не будут мудрее. 1005 *

Хороший Java-пример этого принципа и того, как такой проект будет структурирован, можно найти здесь, на моем сайте: http://www.jeenisoftware.com/maven-dip-principle-example/

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

Answer 3

Проектирование интерфейсов (как вариант проектирование по контракту ) поддерживает инверсию зависимостей. Оба уменьшают сцепление. Тем не менее:

• Разработка интерфейсов и DBC ничего не говорит о том, как создаются объекты (например, DIP, абстрактные фабрики , фабричные методы ).
• Инверсия зависимостей (внедрение зависимостей ) обычно опирается на интерфейсы, но фокусируется на жизненном цикле объекта, а не на дизайне класса. Вы можете использовать DIP с абстрактными базовыми классами, если хотите, так что вы на самом деле не привержены чистым интерфейсам.

Подходы, как правило, дополняют друг друга.

Answer 4

«проектирование по контракту» и «внедрение зависимостей» очень тесно связаны, но имеют разные уровни абстракции. «проектирование по контракту» является очень общим принципом проектирования, который может поддерживаться различными методами; В языке, в котором есть Java-подобная система классов, вы можете использовать интерфейсы, чтобы избежать конкретных зависимостей классов. «Внедрение зависимостей» - это еще один метод, который часто основывается на существовании интерфейсов для работы (но это не всегда нужно делать - это зависит от языка). Я бы сказал, что «внедрение зависимостей» поддерживает принцип «проектирования по контракту».