Como explicar a injeção de dependência para uma criança de 5 anos?

O que é uma boa maneira de explicar a injeção de dependência ?

Eu encontrei vários tutoriais no Google, mas nenhum deles supõe que o leitor seja apenas um iniciante em Java. Como você explicaria isso para um novato?

Eu te dou injeção de dependência para crianças de cinco anos.

Quando você vai e tira coisas da geladeira para si mesmo, você pode causar problemas. Você pode deixar a porta aberta, você pode ter algo que mamãe ou papai não querem que você tenha. Você pode até estar procurando por algo que nem sequer tenhamos ou que tenha expirado.

O que você deve fazer é declarar uma necessidade, “eu preciso de algo para beber com o almoço”, e então vamos ter certeza de que você tem algo quando se sentar para comer.

O que sobre isso?

Se você tiver uma class Employee e esse funcionário tiver um Address você poderá ter a class Employee definida 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 uma relação HAS-A entre o funcionário e seu endereço, tudo bem.

Agora, esse relacionamento do HAS-A criou uma dependência entre eles. O problema vem dentro do construtor.

Sempre que você quiser criar uma instância de Employee precisará de uma instância de Address :

  Address someAddress = .... Employee oscar = new Employee( someAddress ); 

Trabalhar dessa maneira torna-se problemático, especialmente quando você deseja realizar testes de unidade.

O principal problema surge quando você precisa testar um object específico, você precisa criar uma instância de outro object, e muito provavelmente você precisa criar uma instância de outro object para fazer isso. A cadeia pode se tornar incontrolável.

Para evitar isso, você poderia mudar o construtor assim:

  public Employee(){ } 

Usando um construtor sem argumentos.

Então você pode definir o endereço sempre que quiser:

  Address someAddress = .... Employee oscar = new Employee(); oscar.setAddress( someAddress ); 

Agora, isso pode ser um empecilho, se você tiver vários atributos ou se os objects forem difíceis de criar.

No entanto, pense nisso, digamos, adicione o atributo Department :

  class Employee { private Address address; private Department department; .... 

Se você tem 300 funcionários, e todos eles precisam ter o mesmo departamento, e mais o mesmo departamento precisa ser compartilhado entre alguns outros objects (como a lista de departamentos da empresa ou os papéis que cada departamento tem, etc.), então você ter dificuldade com a visibilidade do object Department e compartilhá-lo através de toda a rede de objects.

O que é a Injeção de Dependência para ajudá-lo a “injetar” essas dependencies em seu código. A maioria dos frameworks permite que você faça isso especificando em um arquivo externo, qual object deve ser injetado.

Suponha um arquivo de propriedades para um injetor de dependência fictícia:

  #mock employee employee.address = MockAddress.class employee.department = MockDepartment.class #production setup employee.address = RealAddress.class employee.department = RealDepartment.class 

Você vai definir o que injetar para um determinado cenário.

O que a estrutura do Injector de Dependência fará é definir os objects corretos para você, para que você não precise codificar setAddress ou setDepartment . Isso seria feito por reflection ou por geração de código ou outras técnicas.

Portanto, da próxima vez que você precisar testar a class Employee poderá injetar objects simulados de Address e Departments sem precisar codificar todo o conjunto / obtenção para todo o seu teste. Melhor ainda, você pode injetar objects reais de Address e Department em código de produção e ainda ter a confiança de que seu código funciona como testado.

Isso é muito bonito sobre isso.

Ainda não acho que esta explicação é adequada para um 5 anos de idade, como você pediu.

Espero que você ainda ache útil.

Ao escrever uma aula, é natural que ela faça uso de outros objects. Você pode ter uma conexão de database, por exemplo, ou algum outro serviço que você usa. Esses outros objects (ou serviços) são dependencies. A maneira mais simples de escrever o código é simplesmente criar e usar esses outros objects. Mas isso significa que seu object tem um relacionamento inflexível com essas dependencies: não importa porque você está invocando seu object, ele usa as mesmas dependencies.

Uma técnica mais poderosa é poder criar seu object e fornecer dependencies para uso. Portanto, você pode criar uma conexão de database para usar e, em seguida, entregá-la ao seu object. Dessa forma, você pode criar seu object com dependencies diferentes em momentos diferentes, tornando seu object mais flexível. Esta é a injeção de dependência, onde você “injeta” as dependencies no object.

BTW: No estilo de apresentação moderna de usar fotos do Flickr para ilustrar conceitos, isso pode ser ilustrado com um viciado atirando-se com drogas. Oh, espere, isso é dependência de injeção … OK, desculpe, piada de mau gosto.

Eu não sei de nenhum tutorial simplificado, mas posso dar-lhe uma versão de quase 25 250 palavras-ou-menos:

Com a injeção de dependência, um object não configura seus próprios componentes com base em coisas que ele já conhece, em vez disso, o object é configurado por uma lógica de nível superior e, depois, chama componentes dos quais não tinha pré-conhecimento incorporado. A ideia é tornar o object mais de um componente e menos de um aplicativo, realocando tarefas de configuração em um nível mais alto. Isso torna o object mais provável de ser útil no futuro ou com uma configuração diferente.

É melhor para o teste, é melhor quando chega a hora de revisar o aplicativo. Uma implementação típica coloca a configuração em XML e usa uma estrutura para carregar dinamicamente as classs.

Quando você recebe um novo Nintendo, você pode simplesmente usar os botões e a canvas sensível ao toque para jogar.

Mas na fábrica da Nintendo, eles precisam saber como montar um.

Quando as pessoas inteligentes na fábrica trazem um Nintendo DS, ele será diferente por dentro, mas você ainda saberá como usá-lo.