Я понимаю преимущества самой инъекции зависимостей. Возьмем, например, Spring. Я также понимаю преимущества других Spring функций, таких как AOP, помощников разных типов и т.д. Мне просто интересно, каковы преимущества конфигурации XML, такие как:
<bean id="Mary" class="foo.bar.Female">
<property name="age" value="23"/>
</bean>
<bean id="John" class="foo.bar.Male">
<property name="girlfriend" ref="Mary"/>
</bean>
по сравнению с обычным старым java-кодом, например:
Female mary = new Female();
mary.setAge(23);
Male john = new Male();
john.setGirlfriend(mary);
который легче отлаживается, время компиляции проверяется и может быть понято всем, кто знает только java. Итак, какова основная цель рамки инъекций зависимостей? (или фрагмент кода, который показывает его преимущества.)
UPDATE:
В случае
IService myService;// ...
public void doSomething() {
myService.fetchData();
}
Как может структура IoC угадать, какую реализацию myService я хочу ввести, если ее несколько? Если есть только одна реализация данного интерфейса, и я позволяю контейнеру IoC автоматически решать использовать его, он будет прерван после появления второй реализации. И если есть намеренно только одна возможная реализация интерфейса, тогда вам не нужно вводить его.
Было бы очень интересно увидеть небольшую часть конфигурации для IoC, которая показывает, что это выгодно. Я использовал Spring какое-то время, и я не могу представить такой пример. И я могу показать отдельные строки, которые демонстрируют преимущества спящего режима, dwr и других фреймворков, которые я использую.
ОБНОВЛЕНИЕ 2:
Я понимаю, что конфигурация IoC может быть изменена без повторной компиляции. Это действительно такая хорошая идея? Я могу понять, когда кто-то хочет изменить учетные данные БД без перекомпиляции - он может быть не разработчиком. В вашей практике, как часто кто-то другой, кроме разработчика, меняет конфигурацию IoC? Я думаю, что для разработчиков нет усилий перекомпилировать этот конкретный класс вместо изменения конфигурации. А для не-разработчиков вы, вероятно, захотите сделать свою жизнь проще и предоставить более простой конфигурационный файл.
ОБНОВЛЕНИЕ 3:
Внешняя конфигурация отображения между интерфейсами и их конкретными реализациями
Что хорошего в том, чтобы сделать его extenal? Вы не делаете весь свой код внешним, в то время как вы определенно можете - просто поместите его в файл ClassName.java.txt, прочитайте и скомпилируйте вручную на лету - ничего себе, вы избежали перекомпиляции. Почему следует избегать компиляции?!
Вы сохраняете время кодирования, потому что вы предоставляете сопоставления декларативно, а не в процедурный код
Я понимаю, что иногда декларативный подход экономит время. Например, я объявляю только один раз, когда сопоставление между свойством bean и столбцом базы данных, а спящий режим использует это сопоставление при загрузке, сохранении, построении SQL на основе HSQL и т.д. Здесь работает декларативный подход. В случае Spring (в моем примере) объявление имеет больше строк и имеет ту же выразительность, что и соответствующий код. Если есть пример, когда такое объявление короче кода - я бы хотел его увидеть.
Принцип обращения инверсии позволяет легко тестировать устройство, поскольку вы можете заменить реальные реализации фальшивыми (например, заменить базу данных SQL на встроенную память)
Я понимаю инверсию преимуществ управления (я предпочитаю называть шаблон проектирования, обсуждаемый здесь как Injection Dependency, потому что IoC является более общим - существует много видов контроля, и мы инвертируем только один из них - контроль инициализации), Я спрашивал, почему кому-то нужно что-то другое, кроме языка программирования. Я определенно могу заменить реальные реализации фальшивыми, используя код. И этот код выражает то же самое, что и конфигурация - он просто инициализирует поля с поддельными значениями.
mary = new FakeFemale();
Я понимаю преимущества DI. Я не понимаю, какие преимущества добавляются внешней конфигурацией XML по сравнению с настройкой кода, который делает то же самое. Я не думаю, что компиляции следует избегать - я собираю каждый день, и я все еще жив. Я думаю, что конфигурация DI является плохим примером декларативного подхода. Объявление может быть полезно, если объявлено один раз И используется много раз по-разному - например, hibernate cfg, где сопоставление между свойством bean и столбцом базы данных используется для сохранения, загрузки, построения поисковых запросов и т.д. Spring Конфигурация DI может можно легко перевести на код настройки, как в начале этого вопроса, не так ли? И он используется только для инициализации bean, не так ли? Что означает, что декларативный подход ничего здесь не добавляет, не так ли?
Когда я объявляю отображение hibernate, я просто предоставляю hibernate некоторую информацию, и она работает на основе этого - я не говорю, что делать. В случае spring моя декларация сообщает Spring точно, что делать, поэтому зачем объявлять ее, почему бы просто не сделать это?
ПОСЛЕДНЕЕ ОБНОВЛЕНИЕ:
Ребята, много ответов рассказывают мне об инъекции зависимостей, которые я ЗНАЮ ХОРОШО.
Вопрос заключается в цели конфигурации DI вместо инициализации кода. Я склонен думать, что код инициализации короче и яснее.
Единственный ответ, который я получил до сих пор на мой вопрос, заключается в том, что он избегает перекомпиляции при изменении конфигурации. Я предполагаю, что должен опубликовать еще один вопрос, потому что это большой секрет для меня, почему в этом случае следует избегать компиляции.