Как объяснить инъекцию зависимости к 5-летнему ребенку?

Каков хороший способ объяснить инъекцию зависимостей ?

Я нашел несколько руководств по Google, но ни один из них, который предположил бы, что это читатель, – это просто начинающий Java. Как бы вы объяснили это новичку?

Я даю вам инъекцию зависимостей для пятилетних детей.

Когда вы пойдете и выберете вещи из холодильника для себя, вы можете вызвать проблемы. Вы можете оставить дверь открытой, вы можете получить то, что мама или папа не хотят, чтобы вы имели. Возможно, вы даже ищете что-то, чего у нас нет или которое истекло.

То, что вы должны делать, это заявить о необходимости: «Мне нужно что-нибудь выпить с обедом», а затем мы обязательно удостовериться, что у вас есть что-то, когда вы садитесь, чтобы поесть.

Как насчет этого?

Если у вас есть Employee classа, и у этого сотрудника есть Address вы можете Employee class Employee следующим образом:

 class Employee { private Address address; // constructor public Employee( Address newAddress ) { this.address = newAddress; } public Address getAddress() { return this.address; } public void setAddress( Address newAddress ) { this.address = newAddress; } } 

Пока все прекрасно.

Этот код показывает связь HAS-A между сотрудником и его адресом, это нормально.

Теперь эта связь HAS-A создала зависимость между ними. Проблема входит в конструктор.

Каждый раз, когда вы хотите создать экземпляр Employee вам нужен экземпляр Address :

  Address someAddress = .... Employee oscar = new Employee( someAddress ); 

Работа таким образом становится проблематичной, особенно если вы хотите выполнить модульное тестирование.

Основная проблема возникает, когда вам нужно протестировать один конкретный объект, вам нужно создать экземпляр другого объекта, и, скорее всего, вам нужно создать экземпляр еще одного объекта для этого. Цепь может стать неуправляемой.

Чтобы этого избежать, вы можете изменить конструктор следующим образом:

  public Employee(){ } 

Использование конструктора no args.

Затем вы можете установить адрес, когда захотите:

  Address someAddress = .... Employee oscar = new Employee(); oscar.setAddress( someAddress ); 

Теперь это может быть drag and drop, если у вас есть несколько атрибутов или если объекты трудно создать.

Но подумайте об этом, допустим, добавьте атрибут Department :

  class Employee { private Address address; private Department department; .... 

Если у вас есть 300 сотрудников, и все они должны иметь один и тот же отдел, и плюс тот же отдел должен быть разделен между некоторыми другими объектами (такими как список отделов компаний или ролями каждого отдела и т. Д.), Тогда вы будете с трудом справляются с видимостью объекта « Department и передают его через всю сеть объектов.

В чем заключается Инъекция зависимостей, которая поможет вам «ввести» эти зависимости в ваш код. Большинство фреймворков позволяют это сделать, указав во внешнем файле, какой объект нужно вставить.

Предположим, файл свойств для фиктивного инжектора зависимостей:

  #mock employee employee.address = MockAddress.class employee.department = MockDepartment.class #production setup employee.address = RealAddress.class employee.department = RealDepartment.class 

Вы определите, что нужно вводить для данного сценария.

Что делает инфраструктура Injector Dependency, это установить для вас правильные объекты, поэтому вам не нужно setAddress или setDepartment . Это будет сделано либо путем отражения, либо с помощью генерации кода или других методов.

Итак, в следующий раз, когда вам нужно протестировать class Employee вы можете вводить макеты объектов Address and Departments без необходимости кодирования всего набора / get для всего теста. Еще лучше, вы можете вводить реальные объекты Address и Department в производственный код и по-прежнему иметь уверенность в том, что ваш код работает как проверенный.

Это в значительной степени об этом.

Тем не менее я не думаю, что это объяснение подходит для 5 лет, как вы просили.

Надеюсь, вы по-прежнему считаете это полезным.

При написании classа для него естественно использовать другие объекты. У вас может быть соединение с базой данных, например, или какая-либо другая служба, которую вы используете. Эти другие объекты (или службы) являются зависимыми. Самый простой способ написать код – просто создать и использовать эти другие объекты. Но это означает, что ваш объект имеет негибкую связь с этими зависимостями: независимо от того, почему вы вызываете свой объект, он использует те же зависимости.

Более мощный метод – это возможность создать свой объект и предоставить ему зависимости для использования. Таким образом, вы можете создать подключение к базе данных для использования, а затем передать его вашему объекту. Таким образом, вы можете создать свой объект с различными зависимостями в разное время, что сделает ваш объект более гибким. Это инъекция зависимостей, где вы «вводите» зависимости в объект.

BTW: В современном стиле презентации с использованием фотографий Flickr, чтобы проиллюстрировать концепции, это можно проиллюстрировать с наркоманом, стреляющим в наркотики. О, подождите, это инъекционная зависимость … ОК, извините, неудачная шутка.

Я не знаю каких-либо упрощенных руководств, но я могу дать вам почти 25 250 слов или менее:

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

Лучше тестировать, лучше, когда придет время для пересмотра приложения. Типичная реализация ставит конфигурацию в XML и использует инфраструктуру для динамической загрузки classов.

Когда вам дадут новый Nintendo, вы можете просто использовать кнопки и сенсорный экран для игры в игры.

Но на фабрике Nintendo им нужно знать, как собрать их вместе.

Когда умные люди на заводе выведут Nintendo DS, они будут разными внутри, но вы все равно будете знать, как им пользоваться.

Давайте будем гением компьютера.