Реальные решения с использованием Dependency Injection - PullRequest
21 голосов
/ 21 января 2010

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

Все примеры, которые я видел, связаны с JNDI и тем, как DI помогает вам быть более гибким.

Что такое реальные приложения / проблемы, которые вы решили с помощью DI, которые будет трудно решить другими способами?

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

Ответы [ 8 ]

24 голосов
/ 21 января 2010

Буквально на днях я решил прочитать о внедрении зависимостей. До этого я знал только это слово. Честно говоря, моя реакция на статью Мартина Фаулера была: «Вот так?»

Я должен согласиться с Джеймсом Шором :

«Внедрение зависимости» - это термин на 25 долларов для концепции с 5 центами.

Это вовсе не значит, что это плохая концепция. А если серьезно, когда экземпляр A должен работать с другим экземпляром B, он сводится к следующему выбору:

  1. let A find B:

    Это означает, что B должно быть глобальным. Зла.

  2. let A create B:

    Хорошо, если только A нужно B. Как только C также потребуется B, замените A на C в этом списке. Обратите внимание, что контрольный пример будет C, поэтому, если вы хотите выполнить тестирование, этот выбор также пропал.

  3. дать B до A:

    Это внедрение зависимостей.

Я что-то упустил? (Обратите внимание, что я из мира Python, так что, возможно, есть некоторые специфические для языка пункты, которые я не вижу.)

7 голосов
/ 21 января 2010

Вчера я нашел мобильный телефон в автобусе. Человек, который потерял его, не имел ни малейшего представления о человеке, владеющем ее мобильным телефоном. Я позвонил ее отцу и сказал, что у меня есть мобильный телефон его дочери. Поэтому я ввел зависимость от меня в него. Обычно это случай голливудского принципа: «Не звоните нам (потому что вы не можете!), Мы вам звоним». Позже он пришел и взял телефон своей дочери.

Я бы назвал это реальной проблемой, которую я решил с помощью внедрения зависимостей, не так ли?

По моему мнению, DI не является способом решения проблем, для которых у нас не было бы другого решения. Заводы могут быть еще одним способом решения таких проблем. Таким образом, нет реального ответа на ваш вопрос, потому что DI - это всего лишь один путь, помимо других. Это просто симпатичное бедро, хотя и очень элегантно.

Мне действительно понравился DI, когда у меня были эти DAO, для которых требовался SQLMapper. Мне просто нужно было один раз ввести разные мапперы в класс отца, а остальное было сделано с помощью конфигурации. Это сэкономило мне много времени и средств, но я до сих пор не могу назвать это проблемой, для которой нет другого решения.

4 голосов
/ 21 января 2010

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

Если вы используете Java, я бы порекомендовал Google Guice , так как он так крут. Для C ++ я рекомендую Qt IOC . Для .NET Castle Project предоставляет хорошую систему IOC. Практически везде есть реализация Spring, но это скучно.

3 голосов
/ 21 января 2010

DI позволяет создавать приложения, которые можно настраивать и переконфигурировать, не касаясь самой кодовой базы. Не только URL или настройки, хотя; универсальные объекты могут быть записаны в коде, а затем «настроены» или сконфигурированы с помощью файлов XML для достижения конкретного результата, требуемого для данного случая.

Например, я могу создать класс RegexDetective, где фактическое регулярное выражение, которое он ищет, предоставлено в установщике, а затем в моем XML-файле Spring DI определите одно фактическое выражение регулярного выражения для RegexDetective.setRegex () для развертывания SleuthApp. еду в Лондон. Через несколько дней я могу вернуться и обновить регулярное выражение в XML-файле для другого развертывания SleuthApp с отправкой в ​​Сибирь.

DI также позволяет определять конкретные реализации интерфейсов аналогичным образом, за пределами кодовой базы в XML, чтобы изменять поведение приложения без фактического касания кода, такого как установка реализации AngryDetective или ArcticDetective интерфейса Detective, в файле DI XML.

2 голосов
/ 21 января 2010

Мы запускаем мультимедийный сервис для разных стран. Мы запускаем один и тот же код для всех, но иногда бизнес-правила отличаются в разных странах. В этом случае мы вводим другой Spring MVC Interceptor для одного клиента или для другого.

Затем на этапе развертывания сценарий «выбирает», какой файл DI необходим, основываясь на последних буквах файлов ( fr для Франции, ch для Швейцарии и т. Д. ...)

  • Приложение-context.xml-пт
  • Приложение-context.xml-ч
  • и т.д ...

Это единственное хорошее применение, которое я вижу в DI. Хотя я не фанат DI.

1 голос
/ 21 января 2010

Я использовал контейнер IoC (DI) Spring для последних трех веб-приложений, которые я разработал. Я не думаю, что это подходит для одного конкретного типа проблемы, скорее это другой способ решения проблемы. Это, как вы сказали, более гибкий подход к большим системам. Моя личная любимая особенность DI - то, что вы можете лучше подготовить модульные тесты, потому что ваши классы сильно отделены Также для меня важно повторное использование кода. Поскольку я использую контейнер во многих приложениях, я могу использовать одни и те же компоненты и знать, что их зависимости будут передаваться извне.

0 голосов
/ 21 января 2010

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

0 голосов
/ 21 января 2010

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...