Как объяснить введение зависимости 5-летнему ребенку?
Что такое хороший способ объяснить внедрение зависимости?
Я нашел несколько учебных пособий в Google, но ни один из них не предполагал, что читатель - просто новичок в Java. Как бы вы объяснили это новичку?
5 ответов
Я даю вам инъекцию зависимости для пятилетних.
Когда вы идете и достаете вещи из холодильника для себя, у вас могут возникнуть проблемы. Вы можете оставить дверь открытой, вы можете получить что-то, что мама или папа не хотят, чтобы вы имели. Возможно, вы даже ищете что-то, чего у нас нет или срок действия которого истек.
Что вы должны делать, так это заявлять о необходимости: "Мне нужно что-нибудь выпить с обедом", и тогда мы позаботимся о том, чтобы у вас было что-нибудь, когда вы сядете поесть.
Как насчет этого?
Если у вас есть класс 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(){
}
Использование конструктора без аргументов.
Тогда вы можете установить адрес когда захотите:
Address someAddress = ....
Employee oscar = new Employee();
oscar.setAddress( someAddress );
Теперь это может быть перетаскивание, если у вас есть несколько атрибутов или если объекты сложно создать.
Тем не менее, подумайте об этом, скажем, вы добавляете 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
Вы определите, что вводить для данного сценария.
Платформа Dependency Injector будет делать для вас правильные объекты, чтобы вам не приходилось кодировать setAddress или же setDepartment, Это может быть сделано либо путем отражения, либо путем генерации кода или других методов.
Итак, в следующий раз вам нужно проверить Employee класс вы можете ввести макет Address а также Departments объекты без необходимости кодировать весь набор / получить для всего вашего теста. Даже лучше, вы можете ввести реальный Address а также Department объекты в производственном коде, и при этом сохраняете уверенность, что ваш код работает как проверено.
Это довольно много об этом.
Тем не менее, я не думаю, что это объяснение подходит для 5-летнего возраста, как вы просили.
Я надеюсь, что вы все еще находите это полезным.
При написании класса естественно использовать другие объекты. Например, у вас может быть подключение к базе данных или какой-либо другой сервис, которым вы пользуетесь. Эти другие объекты (или службы) являются зависимостями. Самый простой способ написать код - это просто создать и использовать эти другие объекты. Но это означает, что ваш объект негибко связан с этими зависимостями: независимо от того, почему вы вызываете свой объект, он использует одни и те же зависимости.
Более мощный метод заключается в том, чтобы иметь возможность создавать свой объект и предоставлять ему зависимости для использования. Таким образом, вы можете создать соединение с базой данных и затем передать его вашему объекту. Таким образом, вы можете создавать свой объект с разными зависимостями в разное время, делая ваш объект более гибким. Это внедрение зависимостей, где вы "внедряете" зависимости в объект.
Кстати: в современном стиле презентации с использованием фотографий flickr для иллюстрации концепций это можно проиллюстрировать, когда наркоман застрелился наркотиками. Ой, подождите, это зависимость от инъекций... Хорошо, извините, плохая шутка.
Я не знаю ни одного упрощенного учебника, но могу дать вам почти 25 250 слов или меньше:
При внедрении зависимостей объект не настраивает свои собственные компоненты на основе уже известных ему вещей, скорее объект настраивается с помощью логики более высокого уровня, а затем вызывает компоненты, для которых у него нет встроенного предвидения. Идея состоит в том, чтобы сделать объект более компонентным, а не прикладным, перенести задачи настройки на более высокий уровень. Это повышает вероятность того, что объект будет полезен в будущем или с другой конфигурацией.
Это лучше для тестирования, это лучше, когда приходит время пересмотреть приложение. Типичная реализация помещает конфигурацию в XML и использует платформу для динамической загрузки классов.
Когда вы получаете новый Nintendo, вы можете просто использовать кнопки и сенсорный экран, чтобы играть в игры.
Но на фабрике Nintendo им нужно знать, как их собрать.
Когда умные люди на фабрике выпускают Nintendo DS, внутри все будет по-другому, но вы все равно будете знать, как им пользоваться.