A co z tym?
Jeśli masz klasę, Employeea ten pracownik ją ma Address , możesz ją Employeezdefiniować w następujący sposób:
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;
}
}
Jak dotąd wszystko wygląda dobrze.
Ten kod pokazuje relację HAS-A między pracownikiem a jego adresem, w porządku.
Teraz ta relacja HAS-A stworzyła zależność między nimi. Problem dotyczy konstruktora.
Za każdym razem, gdy chcesz utworzyć Employeeinstancję, potrzebujesz Addressinstancji:
Address someAddress = ....
Employee oscar = new Employee( someAddress );
Praca w ten sposób staje się problematyczna, zwłaszcza gdy chcesz przeprowadzić testy jednostkowe.
Główny problem pojawia się, gdy musisz przetestować jeden konkretny obiekt, musisz utworzyć instancję innego obiektu, a najprawdopodobniej musisz utworzyć instancję jeszcze innego obiektu, aby to zrobić. Łańcuch może stać się niemożliwy do zarządzania.
Aby tego uniknąć, możesz zmienić konstruktor w następujący sposób:
public Employee(){
}
Korzystanie z konstruktora no args.
Następnie możesz ustawić adres, kiedy tylko chcesz:
Address someAddress = ....
Employee oscar = new Employee();
oscar.setAddress( someAddress );
Może to być przeciąganie, jeśli masz kilka atrybutów lub obiekty są trudne do utworzenia.
Pomyśl o tym, powiedzmy, dodajesz Departmentatrybut:
class Employee {
private Address address;
private Department department;
....
Jeśli masz 300 pracowników, a wszyscy muszą mieć ten sam dział, a ten sam dział musi być współużytkowany przez niektóre inne obiekty (takie jak lista firmowa działów lub role każdego działu itp.), Wtedy mają trudności z widocznością Departmentobiektu i udostępnieniem go przez całą sieć obiektów.
Na czym polega Dependence Injection , aby pomóc ci „wstrzyknąć” te zależności do twojego kodu. Większość ram pozwala to zrobić, określając w zewnętrznym pliku, jaki obiekt ma zostać wstrzyknięty.
Załóżmy plik właściwości dla wtryskiwacza fikcyjnej zależności:
#mock employee
employee.address = MockAddress.class
employee.department = MockDepartment.class
#production setup
employee.address = RealAddress.class
employee.department = RealDepartment.class
Zdefiniujesz, co wstrzyknąć dla danego scenariusza.
To, co zrobi platforma Dependency Injector, to ustawienie odpowiednich obiektów dla ciebie, abyś nie musiał kodować setAddressani setDepartment. Odbyłoby się to poprzez refleksję, generowanie kodu lub inne techniki.
Zatem następnym razem, gdy będziesz musiał przetestować Employeeklasę, możesz wstrzyknąć próbkę Addressi Departmentsobiekty bez konieczności kodowania całego zestawu / get dla całego testu. Co więcej, możesz wstrzykiwać rzeczywiste Address i Departmentobiekty do kodu produkcyjnego i nadal mieć pewność, że Twój kod działa zgodnie z testami.
To właściwie tyle.
Nadal nie sądzę, aby to wyjaśnienie było odpowiednie dla 5-latka, jak prosiłeś.
Mam nadzieję, że nadal okaże się przydatny.