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

Ответ 1

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

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

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

Ответ 2

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

Если у вас есть класс Employee, и у этого сотрудника есть Address, вы можете определить класс 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 ); 

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

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

  class Employee {
      private Address address;
      private Department department;

  ....

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

Что означает Injection Dependency Injection, чтобы помочь вам, а "вставить" эти зависимости в ваш код. Большинство фреймворков позволяют это сделать, указав во внешнем файле, какой объект нужно вставить.

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

  #mock employee
  employee.address = MockAddress.class
  employee.department = MockDepartment.class

  #production setup 
  employee.address = RealAddress.class
  employee.department = RealDepartment.class

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Но в Nintendo factory им нужно знать, как их соединить.

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