Как насчет этого?
Если у вас есть класс , 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объекта и поделиться им через всю сеть объектов.
Что Injection Dependency все об этом , чтобы помочь вам, ну, «Inject» эта зависимость в вашем коде. Большинство платформ позволяют вам сделать это, указав во внешнем файле, какой объект должен быть введен.
Предположим, файл свойств для фиктивного инжектора зависимостей:
#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-летнего возраста, как вы просили.
Я надеюсь, что вы все еще находите это полезным.