Che dire di questo?
Se hai una classe Employeee questo dipendente ne ha una Address puoi Employeedefinire la classe come segue:
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;
}
}
Finora sembra tutto a posto.
Questo codice mostra una relazione HAS-A tra il dipendente e il suo indirizzo, va bene.
Ora, questa relazione HAS-A ha creato una dipendenza tra di loro. Il problema si trova nel costruttore.
Ogni volta che vuoi creare Employeeun'istanza hai bisogno di Addressun'istanza:
Address someAddress = ....
Employee oscar = new Employee( someAddress );
Lavorare in questo modo diventa problematico soprattutto quando si desidera eseguire test unitari.
Il problema principale si presenta quando è necessario testare un oggetto particolare, è necessario creare un'istanza di un altro oggetto e molto probabilmente è necessario creare un'istanza di un altro oggetto per farlo. La catena potrebbe diventare ingestibile.
Per evitare ciò, è possibile modificare il costruttore in questo modo:
public Employee(){
}
Utilizzando un costruttore no args.
Quindi puoi impostare l'indirizzo quando vuoi:
Address someAddress = ....
Employee oscar = new Employee();
oscar.setAddress( someAddress );
Ora, questo può essere un trascinamento, se hai diversi attributi o se gli oggetti sono difficili da creare.
Tuttavia, pensaci, diciamo, aggiungi l' Departmentattributo:
class Employee {
private Address address;
private Department department;
....
Se hai 300 dipendenti e tutti devono avere lo stesso dipartimento e inoltre lo stesso dipartimento deve essere condiviso tra alcuni altri oggetti (come l'elenco delle società dei dipartimenti o i ruoli che ogni dipartimento ha ecc.), Allora avrai avere difficoltà con la visibilità Departmentdell'oggetto e condividerlo con tutta la rete di oggetti.
Qual è l' iniezione di dipendenza al riguardo per aiutarti a "iniettare" queste dipendenze nel tuo codice. La maggior parte dei framework ti consente di farlo specificando in un file esterno quale oggetto deve essere iniettato.
Assumi un file delle proprietà per un iniettore di dipendenza fittizio:
#mock employee
employee.address = MockAddress.class
employee.department = MockDepartment.class
#production setup
employee.address = RealAddress.class
employee.department = RealDepartment.class
Definirai cosa iniettare per un determinato scenario.
Quello che farà il framework di Dependency Injector è impostare gli oggetti corretti per te, quindi non devi codificare setAddresso setDepartment. Ciò sarebbe possibile mediante riflessione o generazione di codice o altre tecniche.
Quindi, la prossima volta che devi testare la Employeeclasse, puoi iniettare mock Addresse Departmentsoggetti senza dover codificare tutto il set / ottenere per tutti i tuoi test. Ancora meglio, puoi iniettare oggetti reali Address e Departmentnel codice di produzione e avere comunque la sicurezza che il tuo codice funzioni come testato.
È praticamente tutto.
Comunque non penso che questa spiegazione sia adatta per un bambino di 5 anni come da lei richiesto.
Spero che lo trovi ancora utile.