Que tal isso?
Se você tem uma classe Employeee esse funcionário tem uma, Address você pode Employeedefini-la da seguinte maneira:
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;
}
}
Tudo parece bem até agora.
Este código mostra um relacionamento HAS-A entre o funcionário e o endereço dele, tudo bem.
Agora, esse relacionamento HAS-A criou uma dependência entre eles. O problema vem dentro do construtor.
Cada vez que você deseja criar uma Employeeinstância, você precisa de uma Addressinstância:
Address someAddress = ....
Employee oscar = new Employee( someAddress );
Trabalhar dessa maneira se torna problemático, especialmente quando você deseja executar testes de unidade.
O principal problema vem quando você precisa testar um determinado objeto, você precisa criar uma instância de outro objeto, e, provavelmente, você precisa criar uma instância de ainda outra objeto para fazer isso. A corrente pode se tornar incontrolável.
Para evitar isso, você pode alterar o construtor assim:
public Employee(){
}
Usando um construtor no args.
Depois, você pode definir o endereço quando quiser:
Address someAddress = ....
Employee oscar = new Employee();
oscar.setAddress( someAddress );
Agora, isso pode ser uma chatice, se você tiver vários atributos ou se for difícil criar objetos.
No entanto, pense sobre isso, digamos, você adiciona o Departmentatributo:
class Employee {
private Address address;
private Department department;
....
Se você possui 300 funcionários e todos precisam ter o mesmo departamento, e mais esse mesmo departamento precisa ser compartilhado entre outros objetos (como a lista de departamentos da empresa ou as funções de cada departamento, etc.), você tenha dificuldade com a visibilidade do Departmentobjeto e compartilhe-o através de toda a rede de objetos.
O que é a Injeção de Dependências para ajudar você a "injetar" essas dependências no seu código. A maioria das estruturas permite que você faça isso especificando em um arquivo externo qual objeto deve ser injetado.
Suponha um arquivo de propriedades para um injetor de dependência fictício:
#mock employee
employee.address = MockAddress.class
employee.department = MockDepartment.class
#production setup
employee.address = RealAddress.class
employee.department = RealDepartment.class
Você definirá o que injetar para um determinado cenário.
O que a estrutura do Injector de Dependência fará é definir os objetos corretos para você, para que você não precise codificar setAddressou setDepartment. Isso seria feito por reflexão ou por geração de código ou outras técnicas.
Portanto, da próxima vez que você precisar testar a Employeeclasse, poderá injetar simulação Addresse Departmentsobjetos sem precisar codificar todo o conjunto / obter para todo o seu teste. Ainda melhor, você pode injetar objetos reais Address e Departmentno código de produção e ainda ter a confiança de que seu código funciona como testado.
É praticamente isso.
Ainda não acho que essa explicação seja adequada para crianças de 5 anos, conforme solicitado.
Espero que você ainda ache útil.