Я подробно читал о DI, и это кажется интересным. Пока я полностью живу без него.
Все примеры, которые я видел, связаны с JNDI и как DI помогает вам быть более гибкими.
Что такое реальные приложения/проблемы, которые вы решили с помощью DI, которые трудно решить другими способами?
UPDATE
Все ответы до сих пор воспитывают, но, чтобы перефразировать вопрос, я ищу примеры в вашей жизни программирования, что заставило вас сказать, что "эта проблема будет лучше решена с помощью рамки DI".
На днях я решил прочитать об инъекции зависимостей. До тех пор я знал это слово. Честно говоря, моя реакция на Мартина Фаулера article была "Что это?"
Я должен согласиться с James Shore:
"Инъекция зависимостей" - это 25-долларовый термин для 5-процентной концепции.
Это вовсе не означает, что это плохая концепция. Но если серьезно, когда экземпляр A должен работать с другим экземпляром B, это сводится к следующим вариантам:
let A найти B:
Это означает, что B должен быть глобальным. Зло.
let A создать B:
Хорошо, если только A требуется B. Как только C также потребуется B, замените A на C в этом списке. Обратите внимание, что тестовый пример будет C, поэтому, если вы хотите протестировать, этот выбор также ушел.
дать B до A:
Эта инъекция зависимостей.
Я что-то упустил? (Обратите внимание, что я из мира Python, поэтому, возможно, есть конкретные языковые точки, которые я не вижу.)
Я бы назвал эту проблему реальным миром, которую я решил путем инъекции зависимостей, не так ли?
На мой взгляд, DI - это не способ решения проблем, для которого у нас не было бы другого решения. Фабрики могут быть другим способом решения таких проблем. Таким образом, нет никакого реального ответа на ваш вопрос, потому что DI - это всего лишь один из способов, кроме других. Это просто милый, хотя очень элегантный способ.
Мне действительно понравилось DI, когда у меня были эти DAO, которым нужен SQLMapper. Мне просто приходилось вводить разные картографы в класс отца один раз, а остальное - по конфигурации. Сохранял мне много времени и LOC, но я все еще не могу назвать эту проблему, для которой нет другого решения.
Я использую инъекцию зависимости для тестирования все время. Это также очень полезно, когда у вас есть куча больших систем, которые вы не хотите напрямую связывать (очень свободная связь).
Если вы используете Java, я бы рекомендовал Google Guice, так как он так сильно сказывается. Для С++ я рекомендую Qt IOC. Для .NET Castle Project обеспечивает хорошую систему МОК. Существует также реализация Spring в основном везде, но это скучно.
DI позволяет создавать приложения, которые можно настроить и перенастроить, не касаясь самой кодовой базы. Не только URL или настройки; общие объекты могут быть записаны в коде, а затем "настроены" или настроены через файлы XML для достижения конкретного результата, желаемого для данного случая.
Например, я могу создать класс RegexDetective, где фактическое регулярное выражение, которое он ищет, предоставляется в сеттере, а затем в моем XML файле Spring DI определить одно фактическое выражение регулярного выражения для RegexDetective.setRegex() для развертывания из SleuthApp отправляется в Лондон. Затем через несколько дней я могу вернуться и обновить регулярное выражение в файле XML для другого развертывания SleuthApp, отправляющегося в Сибирь.
DI также позволяет определять конкретные реализации интерфейсов аналогичным образом, за пределами базы кода в XML, для изменения поведения приложения без фактического касания кода, такого как установка AngryDetective или ArcticDetective реализации интерфейса Detective, в файле DI XML.
Мы запускаем мультимедийный сервис для разных стран. Мы запускаем один и тот же код для всех, но иногда, бизнес-правила отличаются от одной страны к другой. В этом случае мы добавляем другой Spring MVC Interceptor для одного клиента или другого.
Затем на этапе развертывания script "выбирает", какой файл DI необходим, на основе последних букв файлов (fr для Франции, ch для Швейцарии и т.д.)
Это единственное хорошее применение, которое я вижу в DI. Я не поклонник DI, хотя.
Я использовал контейнер Spring IoC (DI) для последних трех веб-приложений, которые я разработал. Я не думаю, что он подходит для одного конкретного типа проблемы, а это другой способ решения проблемы. Это, как вы сказали, более гибкий подход к крупным системам. Мои личные любимые функции DI - это то, что вы можете подготовить более совершенные модульные тесты, потому что ваши классы сильно развязаны. Для меня также важно повторное использование кода. Поскольку я использую контейнер во многих приложениях, я могу использовать одни и те же компоненты и знать, что их зависимости будут поступать извне.
В больших многомодульных приложениях, использующих DI, модуль зависит только от интерфейсов на соавторах его классов, который сокращает графики зависимостей времени компиляции.
В контексте фреймворков (вызывая "ваш" функциональный код, а не функциональный код, вызывающий библиотеку), это необходимо. В вашем коде могут быть компиляции зависимостей с фреймворком, но мы все знаем, что структура (из ваших рук) не может скомпилировать зависимости с вашим кодом; -)
Я использую DI прежде всего для простоты тестирования. Кроме того, это способствует модели завершения ваших вызовов обслуживания для обеспечения изоляции и возможности реализации независимо от разработки службы.