Как Spring (DI) помогает в разработке, подключая компоненты?

Question

Я изучил Spring довольно давно (просто учусь, без реального практического опыта в реальном проекте). В моем понимании, Spring предоставляет DI-фреймворки, которые позволяют централизовать способ соединения / подключения всех классов в одном месте. Сами классы не составляют / не создают другие компоненты.

Я могу понять, что DI позволяет проще модульное тестирование для каждого компонента, так как они зависят от интерфейса.

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

Answer 1

Эта ссылка на DI объясняет это довольно хорошо: http://en.wikipedia.org/wiki/Dependency_injection#Motivation

Основная цель шаблона внедрения зависимостей состоит в том, чтобы сделать возможным выбор из нескольких реализаций данного интерфейса зависимостей во время выполнения или через файлы конфигурации, а не во время компиляции. Шаблон особенно полезен для обеспечения «ложных» тестовых реализаций сложных компонентов при тестировании; но часто используется для поиска компонентов плагина, а также для поиска и инициализации программных служб.

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

Answer 2

Улучшает качество вашего кода за счет уменьшения связи между классами.

Если класс создает экземпляр другого класса, то существует прямая зависимость между двумя классами (= тесная связь). Так, например, если класс A имеет связь с интерфейсом B, если класс A обрабатывает создание экземпляров интерфейса B, то класс A должен указывать конкретную реализацию для создания экземпляров, и эти классы становятся тесно связанными.

Допустим, у нас есть следующий интерфейс:

interface B{}

, а затем следующий класс

class A{

    private B b = new BImpl();

...
}

В приведенном выше примере (без DI) класс A имеет явную зависимость от BImpl, что означает, что если вы когда-нибудь захотите использовать другую реализацию B, вам также придется изменить класс A.

DI (и слабая связь в целом) нацелены на удаление такого рода зависимостей и имеют кодовую базу, где изменения в одной части кода не «колеблются» во всем приложении, требуя большого количества изменений. Приведенный выше пример довольно тривиален, но если у вас есть кодовая база среднего и большого размера с жесткой связью, эта проблема может быть довольно серьезной.

Answer 3

Концепция DI не зависит от пружины. Внедрение зависимостей возможно даже без использования Spring. То есть ручное внедрение зависимости также возможно.

Пожалуйста, ознакомьтесь с примером Java, приведенным в вики: - http://en.wikipedia.org/wiki/Dependency_injection#Manually_injected_dependency

DI Основное назначение - слабая связь.

Spring обеспечивает IOC (инверсия управления). Когда мы используем Spring для внедрения зависимости с помощью Spring IOC, мы получаем такие функции, как:

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

2) При изменении зависимости не нужно менять код / ​​компиляцию.

3) Более легкое и быстрое тестирование. Следовательно, может покрыть больше случаев в то же время, что приводит к хорошему продукту.

4) Spring предоставляет множество различных шаблонов, облегчающих жизнь разработчикам. Все эти шаблоны используют концепцию DI / Ioc. Приводит к ускорению цикла разработки. Такие шаблоны доступны для пакетной обработки, операций JMS, JMX, JDBC и многих других.

Answer 4

почему централизация проводки всех классов

Централизованная конфигурация - это деталь реализации, а не часть DI.Например, Guice может немного распространить конфигурацию (я не использовал Spring в гневе, поэтому не могу комментировать).

почему происходит подключение всех классов ... внешне

Поскольку это позволяет изменить реализацию.DI не единственный способ, но он самый популярный.Фабрики и Сервис Локаторы являются основными альтернативами.Без какого-либо способа замены тестирование реализации становится практически невозможным.

процесс разработки (помимо тестирования)

Тестирование является очень важной частью.Само по себе это хорошая причина для разделения создания и использования.

В отличие от двух других методов, описанных выше, и прямая инициализация DI также делает видимыми зависимости (особенно внедрение ctor), это может помочь другим пользователям класса.Делая зависимости видимыми, вы можете использовать их для предупреждения о том, что ваш класс делает слишком много (так как для этого потребуется много зависимостей).