O que é injeção de dependência?

Várias perguntas já foram postadas com perguntas específicas sobre injeção de dependência , como quando usá-la e quais estruturas estão lá para ela. Contudo,

O que é injeção de dependência e quando / por que deve ou não deve ser usado?

Basicamente, em vez de ter seus objects criando uma dependência ou pedindo a um object de fábrica para fazer um para eles, você passa as dependencies necessárias para o object externamente, e você torna o problema de outra pessoa. Esse “alguém” é um object mais adiante no gráfico de dependência ou um injetor de dependência (framework) que constrói o gráfico de dependência. Uma dependência como eu estou usando aqui é qualquer outro object que o object atual precisa manter uma referência.

Uma das principais vantagens da injeção de dependência é que ela pode tornar os lotes de teste mais fáceis. Suponha que você tenha um object que em seu construtor faça algo como:

public SomeClass() { myObject = Factory.getObject(); } 

Isso pode ser problemático quando tudo que você quer fazer é executar alguns testes de unidade em SomeClass, especialmente se myObject é algo que faz disco complexo ou access à rede. Então agora você está olhando para mocking myObject mas também de alguma forma interceptar a chamada de fábrica. Difícil. Em vez disso, passe o object como um argumento para o construtor. Agora você mudou o problema para outro lugar, mas o teste pode se tornar muito mais fácil. Basta fazer um myObject fictício e passar isso para dentro. O construtor agora seria parecido com:

 public SomeClass (MyClass myObject) { this.myObject = myObject; } 

Este é um estilo de injeção de dependência – através do construtor. Vários mecanismos são possíveis.

  • Conforme observado nos comentários, uma alternativa comum é definir um construtor do-nothing e ter as dependencies injetadas por meio de setters de propriedades (h / t @MikeVella).
  • Martin Fowler documenta uma terceira alternativa (h / t @MarcDix), onde as classs explicitamente implementam uma interface para as dependencies que desejam injetadas.

Quando não estiver usando injeção de dependência (como em classs que fazem muito trabalho em seus construtores, etc.), tende a se tornar muito mais difícil isolar componentes no teste de unidade.

Em 2013, quando escrevi essa resposta, esse era um tema importante no Blog de testes do Google . Isso continua a ser a maior vantagem para mim, pois você pode nem sempre precisar da flexibilidade extra em seu design de tempo de execução (por exemplo, para localizador de serviço ou padrões semelhantes), mas geralmente é necessário isolar suas classs durante os testes.

A melhor definição que encontrei até agora é a de James Shore :

“Injeção de Dependência” é um termo de 25 dólares para um conceito de 5 centavos. […] dependency injection significa dar a um object suas variables ​​de instância. […].

Há um artigo de Martin Fowler que pode ser útil também.

dependency injection é basicamente fornecer os objects que um object precisa (suas dependencies) em vez de fazê-lo construí-los. É uma técnica muito útil para testes, pois permite que as dependencies sejam ridicularizadas ou apagadas.

Dependências podem ser injetadas em objects por vários meios (como injeção de construtor ou injeção de setter). Pode-se até usar estruturas especializadas de injeção de dependência (por exemplo, Spring) para fazer isso, mas elas certamente não são necessárias. Você não precisa que essas estruturas tenham injeção de dependência. Instanciar e passar objects (dependencies) explicitamente é uma injeção tão boa quanto a injeção pelo framework.

Eu encontrei este exemplo engraçado em termos de acoplamento solto :

Qualquer aplicativo é composto de muitos objects que colaboram entre si para executar algumas coisas úteis. Tradicionalmente, cada object é responsável por obter suas próprias referências aos objects dependentes (dependencies) com os quais colabora. Isso leva a classs altamente acopladas e a códigos difíceis de testar.

Por exemplo, considere um object Car .

Um Car depende de rodas, motor, combustível, bateria, etc. Tradicionalmente, definimos a marca desses objects dependentes juntamente com a definição do object Car .

Sem injeção de dependência (DI):

 class Car{ private Wheel wh = new NepaliRubberWheel(); private Battery bt = new ExcideBattery(); //The rest } 

Aqui, o object Car é responsável por criar os objects dependentes.

E se quisermos mudar o tipo de seu object dependente – digamos Wheel – depois que o NepaliRubberWheel() inicial NepaliRubberWheel() perfurar? Precisamos recriar o object Car com sua nova dependência, como ChineseRubberWheel() , mas somente o fabricante Car pode fazer isso.

Então, o que a Dependency Injection nos faz por …?

Ao usar a injeção de dependência, os objects recebem suas dependencies no tempo de execução, em vez do tempo de compilation (tempo de fabricação do carro) . Para que possamos agora mudar a Wheel sempre que quisermos. Aqui, a dependency ( wheel ) pode ser injetada no Car em tempo de execução.

Depois de usar a injeção de dependência:

Aqui, estamos injetando as dependencies (roda e bateria) em tempo de execução. Daí o termo: Injeção de Dependência.

 class Car{ private Wheel wh = [Inject an Instance of Wheel (dependency of car) at runtime] private Battery bt = [Inject an Instance of Battery (dependency of car) at runtime] Car(Wheel wh,Battery bt) { this.wh = wh; this.bt = bt; } //Or we can have setters void setWheel(Wheel wh) { this.wh = wh; } } 

Fonte: Entendendo a injeção de dependência

dependency injection é uma prática em que os objects são projetados de uma maneira em que eles recebem instâncias dos objects de outras partes do código, em vez de construí-los internamente. Isto significa que qualquer object implementando a interface que é requerida pelo object pode ser substituído sem alterar o código, o que simplifica o teste e melhora o desacoplamento.

Por exemplo, considere estas clases:

 public class PersonService { public void addManager( Person employee, Person newManager ) { ... } public void removeManager( Person employee, Person oldManager ) { ... } public Group getGroupByManager( Person manager ) { ... } } public class GroupMembershipService() { public void addPersonToGroup( Person person, Group group ) { ... } public void removePersonFromGroup( Person person, Group group ) { ... } } 

Neste exemplo, a implementação de PersonService::addManager e PersonService::removeManager precisaria de uma instância do GroupMembershipService para fazer seu trabalho. Sem Dependency Injection, a maneira tradicional de fazer isso seria instanciar um novo GroupMembershipService no construtor do PersonService e usar esse atributo de instância em ambas as funções. No entanto, se o construtor do GroupMembershipService tiver vários requisitos, ou, pior ainda, houver alguns “setters” de boot que precisam ser chamados no GroupMembershipService , o código cresce rapidamente, e o PersonService agora depende não apenas do GroupMembershipService mas também tudo o mais que o GroupMembershipService depende. Além disso, a vinculação ao GroupMembershipService é codificada PersonService no PersonService que significa que você não pode ” GroupMembershipService ” um GroupMembershipService para fins de teste ou usar um padrão de estratégia em diferentes partes de seu aplicativo.

Com a Injeção de Dependência, em vez de instanciar o GroupMembershipService no seu PersonService , você pode passá-lo para o construtor PersonService ou então adicionar uma Property (getter e setter) para definir uma instância local dele. Isso significa que o seu PersonService não precisa mais se preocupar com como criar um GroupMembershipService , ele apenas aceita os que são fornecidos e trabalha com eles. Isso também significa que qualquer coisa que seja uma subclass de GroupMembershipService ou implemente a interface GroupMembershipService pode ser “injetada” no PersonService , e o PersonService não precisa saber sobre a alteração.

A resposta aceita é boa – mas eu gostaria de acrescentar que DI é muito parecido com o clássico evitando constantes constantes no código.

Quando você usa alguma constante como um nome de database, você o move rapidamente de dentro do código para algum arquivo de configuração e passa uma variável contendo esse valor para o local onde é necessário. A razão para fazer isso é que essas constantes geralmente mudam com mais freqüência do que o restante do código. Por exemplo, se você quiser testar o código em um database de teste.

DI é análogo a isso no mundo da programação orientada a objects. Os valores lá, em vez de literais constantes, são objects inteiros – mas o motivo para mover o código criando-os a partir do código de class é semelhante – os objects mudam com mais frequência do que o código que os utiliza. Um caso importante em que tal mudança é necessária é o teste.

Vamos imaginar que você queira ir pescar:

  • Sem injeção de dependência, você precisa cuidar de tudo sozinho. Você precisa encontrar um barco, comprar uma vara de pescar, procurar por iscas, etc. É possível, é claro, mas isso coloca muita responsabilidade em você. Em termos de software, isso significa que você precisa fazer uma pesquisa para todas essas coisas.

  • Com a injeção de dependência, outra pessoa cuida de toda a preparação e disponibiliza o equipamento necessário para você. Você receberá (“injetado”) o barco, a vara de pescar e a isca – tudo pronto para uso.

Esta é a explicação mais simples sobre Container de Injeção de Dependência e Injeção de Dependência que eu já vi:

Sem injeção de dependência

  • A aplicação precisa de Foo (por exemplo, um controlador), então:
  • Aplicação cria Foo
  • Aplicativo chama Foo
    • Foo precisa de Bar (por exemplo, um serviço), então:
    • Foo cria Bar
    • Foo chama Bar
      • A barra precisa de Bim (um serviço, um repository,…), então:
      • Bar cria Bim
      • Bar faz algo

Com injeção de dependência

  • A aplicação precisa de Foo, que precisa de Bar, que precisa de Bim, então:
  • Aplicativo cria Bim
  • Aplicação cria Bar e dá Bim
  • Aplicação cria Foo e dá Barra
  • Aplicativo chama Foo
    • Foo chama Bar
      • Bar faz algo

Usando um Container de Injeção de Dependência

  • Aplicação precisa Foo so:
  • O aplicativo obtém Foo do contêiner, portanto:
    • Recipiente cria Bim
    • Container cria Bar e dá Bim
    • Container cria Foo e dá Bar
  • Aplicativo chama Foo
    • Foo chama Bar
      • Bar faz algo

Dependência Injeção e dependência Injeção Contêineres são coisas diferentes:

  • dependency injection é um método para escrever um código melhor
  • um contêiner DI é uma ferramenta para ajudar a injetar dependencies

Você não precisa de um contêiner para fazer a injeção de dependência. No entanto, um contêiner pode ajudá-lo.

Vamos tentar um exemplo simples com as classs Car e Engine , qualquer carro precisa de um motor para ir a qualquer lugar, pelo menos por enquanto. Então, abaixo, como o código ficará sem injeção de dependência.

 public class Car { public Car() { GasEngine engine = new GasEngine(); engine.Start(); } } public class GasEngine { public void Start() { Console.WriteLine("I use gas as my fuel!"); } } 

E para instanciar a class Car, usaremos o próximo código:

 Car car = new Car(); 

O problema com este código que nós acoplamos fortemente ao GasEngine e se nós decidirmos mudá-lo para o ElectricityEngine, então nós precisaremos rewrite a class Car. E quanto maior o aplicativo, mais problemas e dor de cabeça, teremos que adicionar e usar um novo tipo de mecanismo.

Em outras palavras, com essa abordagem, nossa class Car de alto nível depende da class GasEngine de nível inferior, que viola o Princípio de Inversão de Dependência (DIP) do SOLID. O DIP sugere que devemos depender de abstrações, não de classs concretas. Então, para satisfazer isso, introduzimos a interface IEngine e reescrevemos o código como abaixo:

  public interface IEngine { void Start(); } public class GasEngine : IEngine { public void Start() { Console.WriteLine("I use gas as my fuel!"); } } public class ElectricityEngine : IEngine { public void Start() { Console.WriteLine("I am electrocar"); } } public class Car { private readonly IEngine _engine; public Car(IEngine engine) { _engine = engine; } public void Run() { _engine.Start(); } } 

Agora nossa class Car depende apenas da interface IEngine, não de uma implementação específica do mecanismo. Agora, o único truque é como criamos uma instância do carro e damos a ela uma class concreta de Engine, como GasEngine ou ElectricityEngine. É aí que entra a injeção de dependência .

  Car gasCar = new Car(new GasEngine()); gasCar.Run(); Car electroCar = new Car(new ElectricityEngine()); electroCar.Run(); 

Aqui, basicamente, injetamos (passamos) nossa dependência (instância do mecanismo) para o construtor Car. Então, agora nossas classs têm um baixo acoplamento entre objects e suas dependencies, e podemos facilmente adicionar novos tipos de motores sem alterar a class Car.

O principal benefício da Injeção de Dependência é que as classs são mais fracamente acopladas, porque elas não têm dependencies codificadas. Isto segue o Princípio de Inversão de Dependência, que foi mencionado acima. Em vez de referenciar implementações específicas, as classs solicitam abstrações (geralmente interfaces ) que são fornecidas a elas quando a class é construída.

Assim, no final, a injeção de dependência é apenas uma técnica para obter um acoplamento flexível entre objects e suas dependencies. Em vez de instanciar diretamente as dependencies de que a class precisa para executar suas ações, as dependencies são fornecidas à class (com mais freqüência) por meio da injeção de construtor.

Além disso, quando temos muitas dependencies, é uma boa prática usar contêineres de Inversão de Controle (IoC), que podemos identificar quais interfaces devem ser mapeadas para quais implementações concretas para todas as nossas dependencies e podemos resolvê-las quando construir nosso object. Por exemplo, podemos especificar no mapeamento para o contêiner IoC que a dependência IEngine deve ser mapeada para a class GasEngine e quando solicitarmos ao contêiner IoC uma instância de nossa class Car , ela construirá automaticamente nossa class Car com uma dependência GasEngine Transmitido.

UPDATE: Assistiu ao curso sobre EF Core de Julie Lerman recentemente e também gostou de sua curta definição sobre DI.

dependency injection é um padrão para permitir que seu aplicativo injete objects em tempo real para as classs que precisam deles, sem forçar essas classs a serem responsáveis ​​por esses objects. Ele permite que seu código seja mais solto, e o Entity Framework Core conecta-se a esse mesmo sistema de serviços.

Não “injeção de dependência” significa apenas usar construtores parametrizados e setters públicos?

O artigo de James Shore mostra os seguintes exemplos para comparação .

Construtor sem injeção de dependência:

 public class Example { private DatabaseThingie myDatabase; public Example() { myDatabase = new DatabaseThingie(); } public void doStuff() { ... myDatabase.getData(); ... } } 

Construtor com injeção de dependência:

 public class Example { private DatabaseThingie myDatabase; public Example(DatabaseThingie useThisDatabaseInstead) { myDatabase = useThisDatabaseInstead; } public void doStuff() { ... myDatabase.getData(); ... } } 

O que é injeção de dependência (DI)?

Como outros disseram, a Injeção de Dependência (DI) remove a responsabilidade da criação direta e do gerenciamento do tempo de vida de outras instâncias de object sobre as quais nossa class de interesse (class de consumidor) é dependente (no sentido da UML ). Em vez disso, essas instâncias são passadas para nossa class consumer, normalmente como parâmetros de construtor ou por meio de setters de propriedade (o gerenciamento do object de dependência que instancia e passa para a class de consumidor é normalmente executado por um contêiner de Inversion of Control (IoC) , mas isso é outro tópico) .

DI, DIP e SOLID

Especificamente, no paradigma dos princípios SOLID do Projeto Orientado a Objetos , de Robert C Martin, a DI é uma das possíveis implementações do Princípio da Inversão de Dependência (DIP) . O DIP é o D do mantra SOLID – outras implementações DIP incluem o Service Locator e padrões de Plugin.

O objective do DIP é dissociar as dependencies apertadas e concretas entre as classs e, em vez disso, soltar o acoplamento por meio de uma abstração, que pode ser obtida através de uma interface , abstract class ou pure virtual class , dependendo da linguagem e abordagem utilizada. .

Sem o DIP, nosso código (eu chamei isso de ‘class consumidora’) está diretamente acoplado a uma dependência concreta e também é frequentemente sobrecarregado com a responsabilidade de saber como obter e gerenciar uma instância dessa dependência, ou seja, conceitualmente:

 "I need to create/use a Foo and invoke method `GetBar()`" 

Considerando que, após a aplicação do DIP, o requisito é afrouxado, e a preocupação de obter e gerenciar a vida útil da dependência de Foo foi removida:

 "I need to invoke something which offers `GetBar()`" 

Por que usar DIP (e DI)?

Desacoplar dependencies entre classs dessa forma permite a fácil substituição dessas classs de dependência por outras implementações que também preencham os pré-requisitos da abstração (por exemplo, a dependência pode ser alternada com outra implementação da mesma interface). Além disso, como outros já mencionaram, possivelmente o motivo mais comum para dissociar classs via DIP é permitir que uma class consumidora seja testada isoladamente, já que essas mesmas dependencies podem agora ser apagadas e / ou ridicularizadas.

Uma conseqüência da DI é que o gerenciamento de vida útil das instâncias de objects de dependência não é mais controlado por uma class consumidora, pois o object de dependência agora é passado para a class consumidora (via injeção de construtor ou setter).

Isso pode ser visto de diferentes maneiras:

  • Se o controle de tempo de vida das dependencies pela class consumidora precisar ser retido, o controle poderá ser restabelecido com a injeção de uma fábrica (abstrata) para criar as instâncias da class de dependência na class do consumidor. O consumidor poderá obter instâncias por meio de um Create na fábrica, conforme necessário, e descartar essas instâncias depois de concluídas.
  • Ou, o controle de tempo de vida das instâncias de dependência pode ser liberado para um contêiner IoC (mais sobre isso abaixo).

Quando usar DI?

  • Onde provavelmente haverá a necessidade de replace uma dependência por uma implementação equivalente,
  • Sempre que precisar testar os methods de uma class isoladamente de suas dependencies,
  • Onde a incerteza do tempo de vida de uma dependência pode justificar a experimentação (por exemplo, Hey, MyDepClass é thread-safe – e se nós torná-lo um singleton e injetar a mesma instância em todos os consumidores?)

Exemplo

Aqui está uma implementação simples de c #. Dada a class Consuming abaixo:

 public class MyLogger { public void LogRecord(string somethingToLog) { Console.WriteLine("{0:HH:mm:ss} - {1}", DateTime.Now, somethingToLog); } } 

Embora aparentemente inócuo, ele tem duas dependencies static em duas outras classs, System.DateTime e System.Console , que não apenas limitam as opções de saída de logging (o log no console será inútil se ninguém estiver assistindo), mas pior, é difícil para testar automaticamente, dada a dependência de um relógio do sistema não-determinístico.

Podemos, no entanto, aplicar o DIP a essa class, abstraindo a preocupação do registro de data e hora como uma dependência e acoplando o MyLogger apenas a uma interface simples:

 public interface IClock { DateTime Now { get; } } 

Também podemos soltar a dependência do Console para uma abstração, como um TextWriter . A Injeção de Dependência é tipicamente implementada como injeção de constructor (passando uma abstração para uma dependência como um parâmetro para o construtor de uma class consumidora) ou Setter Injection (passando a dependência através de um setXyz() setter ou uma Propriedade .Net com {set;} definiram). A Injeção de Construtor é preferencial, pois isso garante que a class estará em um estado correto após a construção e permitirá que os campos de dependência internos sejam marcados como readonly (C #) ou final (Java). Então, usando injeção de construtor no exemplo acima, isso nos deixa com:

 public class MyLogger : ILogger // Others will depend on our logger. { private readonly TextWriter _output; private readonly IClock _clock; // Dependencies are injected through the constructor public MyLogger(TextWriter stream, IClock clock) { _output = stream; _clock = clock; } public void LogRecord(string somethingToLog) { // We can now use our dependencies through the abstraction // and without knowledge of the lifespans of the dependencies _output.Write("{0:yyyy-MM-dd HH:mm:ss} - {1}", _clock.Now, somethingToLog); } } 

(Um Clock concreto precisa ser fornecido, o que naturalmente poderia reverter para DateTime.Now , e as duas dependencies precisam ser fornecidas por um contêiner IoC via injeção de construtor)

Um Teste de Unidade automatizado pode ser construído, o que prova definitivamente que nosso registrador está funcionando corretamente, já que agora temos controle sobre as dependencies – o tempo, e podemos espionar a saída escrita:

 [Test] public void LoggingMustRecordAllInformationAndStampTheTime() { // Arrange var mockClock = new Mock(); mockClock.Setup(c => c.Now).Returns(new DateTime(2015, 4, 11, 12, 31, 45)); var fakeConsole = new StringWriter(); // Act new MyLogger(fakeConsole, mockClock.Object) .LogRecord("Foo"); // Assert Assert.AreEqual("2015-04-11 12:31:45 - Foo", fakeConsole.ToString()); } 

Próximos passos

A injeção de dependência é invariavelmente associada a um contêiner Inversion of Control (IoC) , para injetar (fornecer) as instâncias de dependência concretas e para gerenciar instâncias de vida útil. Durante o processo de configuração / bootstrapping, os contêineres IoC permitem que os seguintes IoC sejam definidos:

  • mapeamento entre cada abstração e a implementação concreta configurada (por exemplo, “sempre que um consumidor solicitar um IBar , retornar uma instância do ConcreteBar )
  • as políticas podem ser configuradas para o gerenciamento de duração de cada dependência, por exemplo, para criar um novo object para cada instância do consumidor, para compartilhar uma instância de dependência singleton em todos os consumidores, para compartilhar a mesma instância de dependência somente no mesmo thread, etc.
  • Em .Net, os contêineres IoC reconhecem protocolos como IDisposable e assumem a responsabilidade de Disposing dependencies de acordo com o gerenciamento de tempo de vida configurado.

Normalmente, uma vez que os contêineres IoC tenham sido configurados / bootstrap, eles operam perfeitamente em segundo plano, permitindo que o codificador se concentre no código em questão, em vez de se preocupar com dependencies.

A chave para o código amigável ao DI é evitar o acoplamento estático de classs e não usar o new () para a criação de Dependências.

Como no exemplo acima, o desacoplamento de dependencies requer algum esforço de projeto, e para o desenvolvedor, há uma mudança de paradigma necessária para quebrar o hábito de new dependencies diretamente e, em vez disso, confiar no contêiner para gerenciar dependencies.

Mas os benefícios são muitos, especialmente na capacidade de testar exaustivamente sua class de interesse.

Nota : A criação / mapeamento / projeção (via new ..() ) de projeções PTO / POJO / Serialização DTOs / Gráficos de Entidade / Projeções Anônimas JSON et al – ou seja, classs ou registros “Data only” – usados ​​ou retornados de methods não são considerados como Dependências (no sentido UML) e não sujeitos a DI. Using new to project these is just fine.

To make Dependency Injection concept simple to understand. Let’s take an example of switch button to toggle(on/off) a bulb.

Without Dependency Injection

Switch needs to know beforehand which bulb I am connected to (hard-coded dependency). So,

Switch -> PermanentBulb //switch is directly connected to permanent bulb, testing not possible easily

 Switch(){ PermanentBulb = new Bulb(); PermanentBulb.Toggle(); } 

With Dependency Injection

Switch only knows I need to turn on/off whichever Bulb is passed to me. So,

Switch -> Bulb1 OR Bulb2 OR NightBulb (injected dependency)

 Switch(AnyBulb){ //pass it whichever bulb you like AnyBulb.Toggle(); } 

Modifying James Example for Switch and Bulb:

 public class SwitchTest { TestToggleBulb() { MockBulb mockbulb = new MockBulb(); // MockBulb is a subclass of Bulb, so we can // "inject" it here: Switch switch = new Switch(mockBulb); switch.ToggleBulb(); mockBulb.AssertToggleWasCalled(); } } public class Switch { private Bulb myBulb; public Switch() { myBulb = new Bulb(); } public Switch(Bulb useThisBulbInstead) { myBulb = useThisBulbInstead; } public void ToggleBulb() { ... myBulb.Toggle(); ... } }` 

The whole point of Dependency Injection (DI) is to keep application source code clean and stable :

  • clean of dependency initialization code
  • stable regardless of dependency used

Practically, every design pattern separates concerns to make future changes affect minimum files.

The specific domain of DI is delegation of dependency configuration and initialization.

Example: DI with shell script

If you occasionally work outside of Java, recall how source is often used in many scripting languages (Shell, Tcl, etc., or even import in Python misused for this purpose).

Consider simple dependent.sh script:

 #!/bin/sh # Dependent touch "one.txt" "two.txt" archive_files "one.txt" "two.txt" 

The script is dependent: it won’t execute successfully on its own ( archive_files is not defined).

You define archive_files in archive_files_zip.sh implementation script (using zip in this case):

 #!/bin/sh # Dependency function archive_files { zip files.zip "$@" } 

Instead of source -ing implementation script directly in the dependent one, you use an injector.sh “container” which wraps both “components”:

 #!/bin/sh # Injector source ./archive_files_zip.sh source ./dependent.sh 

The archive_files dependency has just been injected into dependent script.

You could have injected dependency which implements archive_files using tar or xz .

Example: removing DI

If dependent.sh script used dependencies directly, the approach would be called dependency lookup (which is opposite to dependency injection ):

 #!/bin/sh # Dependent # dependency look-up source ./archive_files_zip.sh touch "one.txt" "two.txt" archive_files "one.txt" "two.txt" 

Now the problem is that dependent “component” has to perform initialization itself.

The “component”‘s source code is neither clean nor stable because every changes in initialization of dependencies requires new release for “components”‘s source code file as well.

Last words

DI is not as largely emphasized and popularized as in Java frameworks.

But it’s a generic approach to split concerns of:

  • application development ( single source code release lifecycle)
  • application deployment ( multiple target environments with independent lifecycles)

Using configuration only with dependency lookup does not help as number of configuration parameters may change per dependency (eg new authentication type) as well as number of supported types of dependencies (eg new database type).

What is dependency Injection?

Dependency Injection(DI) means to decouple the objects which are dependent on each other. Say object A is dependent on Object B so the idea is to decouple these object from each other. We don’t need to hard code the object using new keyword rather sharing dependencies to objects at runtime in spite of compile time. If we talk about

How Dependency Injection works in Spring:

We don’t need to hard code the object using new keyword rather define the bean dependency in the configuration file. The spring container will be responsible for hooking up all.

Inversion of Control (IOC)

IOC is a general concept and it can be expressed in many different ways and Dependency Injection is one concrete example of IOC.

Two types of Dependency Injection:

  1. Constructor Injection
  2. Setter Injection

1. Constructor-based dependency injection:

Constructor-based DI is accomplished when the container invokes a class constructor with a number of arguments, each representing a dependency on other class.

 public class Triangle { private String type; public String getType(){ return type; } public Triangle(String type){ //constructor injection this.type=type; } }    

2. Setter-based dependency injection:

Setter-based DI is accomplished by the container calling setter methods on your beans after invoking a no-argument constructor or no-argument static factory method to instantiate your bean.

 public class Triangle{ private String type; public String getType(){ return type; } public void setType(String type){ //setter injection this.type = type; } }    

NOTE: It is a good rule of thumb to use constructor arguments for mandatory dependencies and setters for optional dependencies. Note that the if we use annotation based than @Required annotation on a setter can be used to make setters as a required dependencies.

The best analogy I can think of is the surgeon and his assistant(s) in an operation theater, where the surgeon is the main person and his assistant who provides the various surgical components when he needs it so that the surgeon can concentrate on the one thing he does best (surgery). Without the assistant the surgeon has to get the components himself every time he needs one.

DI for short, is a technique to remove a common additional responsibility (burden) on components to fetch the dependent components, by providing them to it.

DI brings you closer to the Single Responsibility (SR) principle, like the surgeon who can concentrate on surgery .

When to use DI : I would recommend using DI in almost all production projects ( small/big), particularly in ever changing business environments 🙂

Why : Because you want your code to be easily testable, mockable etc so that you can quickly test your changes and push it to the market. Besides why would you not when you there are lots of awesome free tools/frameworks to support you in your journey to a codebase where you have more control.

It means that objects should only have as many dependencies as is needed to do their job and the dependencies should be few. Furthermore, an object’s dependencies should be on interfaces and not on “concrete” objects, when possible. (A concrete object is any object created with the keyword new.) Loose coupling promotes greater reusability, easier maintainability, and allows you to easily provide “mock” objects in place of expensive services.

The “Dependency Injection” (DI) is also known as “Inversion of Control” (IoC), can be used as a technique for encouraging this loose coupling.

There are two primary approaches to implementing DI:

  1. Constructor injection
  2. Setter injection

Constructor injection

It’s the technique of passing objects dependencies to its constructor.

Note that the constructor accepts an interface and not concrete object. Also, note that an exception is thrown if the orderDao parameter is null. This emphasizes the importance of receiving a valid dependency. Constructor Injection is, in my opinion, the preferred mechanism for giving an object its dependencies. It is clear to the developer while invoking the object which dependencies need to be given to the “Person” object for proper execution.

Setter Injection

But consider the following example… Suppose you have a class with ten methods that have no dependencies, but you’re adding a new method that does have a dependency on IDAO. You could change the constructor to use Constructor Injection, but this may force you to changes to all constructor calls all over the place. Alternatively, you could just add a new constructor that takes the dependency, but then how does a developer easily know when to use one constructor over the other. Finally, if the dependency is very expensive to create, why should it be created and passed to the constructor when it may only be used rarely? “Setter Injection” is another DI technique that can be used in situations such as this.

Setter Injection does not force dependencies to be passed to the constructor. Instead, the dependencies are set onto public properties exposed by the object in need. As implied previously, the primary motivators for doing this include:

  1. Supporting dependency injection without having to modify the constructor of a legacy class.
  2. Allowing expensive resources or services to be created as late as possible and only when needed.

Here is the example of how the above code would look like:

 public class Person { public Person() {} public IDAO Address { set { addressdao = value; } get { if (addressdao == null) throw new MemberAccessException("addressdao" + " has not been initialized"); return addressdao; } } public Address GetAddress() { // ... code that uses the addressdao object // to fetch address details from the datasource ... } // Should not be called directly; // use the public property instead private IDAO addressdao; 

All the above answers are good, my aim is to explain the concept in a simple way so that anyone without a programming knowledge can also understand concept

Dependency injection is one of the design pattern that help us to create complex systems in a simpler manner.

We can see a wide variety of application of this pattern in our day to day life. Some of the examples are Tape recorder, VCD, CD Drive etc.

Reel-to-reel portable tape recorder, mid-20th century.

The above image is an image of Reel-to-reel portable tape recorder, mid-20th century. Fonte

The primary intention of a tape recorder machine is to record or playback sound.While designing a system it require a reel to record or playback sound or music. we can place the reel inside the machine or we can provide a hook for the reel where it can be placed.if we opt for the second one that is placing a hook for reel, we are getting an added benefit of playing any music by changing the reel. and also reducing the function playing whatever in the reel.

The main benefits we achieved by using dependency injection.

  • High cohesion and loose coupling.
  • Externalizing dependency and looking only on responsibility.
  • Making things as components and to combine to form a large systems with high capabilities.
  • It helps to develop high quality components since they are independently developed they are properly tested.
  • It helps to replace the component with another if one fails.

Now a days these concept forms the basis of well known frameworks in programming world. The Spring Angular etc are the well-known software frameworks built on the top of this concept

Dependency injection is a pattern used to create instances of objects that other objects rely upon without knowing at compile time which class will be used to provide that functionality or simply the way of injecting properties to an object is called dependency injection.

Example for Dependency injection

Previously we are writing code like this

 Public MyClass{ DependentClass dependentObject /* At somewhere in our code we need to instantiate the object with new operator inorder to use it or perform some method. */ dependentObject= new DependentClass(); dependentObject.someMethod(); } 

With Dependency injection, the dependency injector will take off the instantiation for us

 Public MyClass{ /* Dependency injector will instantiate object*/ DependentClass dependentObject /* At somewhere in our code we perform some method. The process of instantiation will be handled by the dependency injector */ dependentObject.someMethod(); } 

You can also read

Difference between Inversion of Control & Dependency Injection

I think since everyone has written for DI, let me ask a few questions..

  1. When you have a configuration of DI where all the actual implementations(not interfaces) that are going to be injected into a class (for eg services to a controller) why is that not some sort of hard-coding?
  2. What if I want to change the object at runtime? For example, my config already says when I instantiate MyController, inject for FileLogger as ILogger. But I might want to inject DatabaseLogger.
  3. Everytime I want to change what objects my AClass needs, I need to now look into two places – The class itself and the configuration file. How does that make life easier?
  4. If Aproperty of AClass is not injected, is it harder to mock it out?
  5. Going back to the first question. If using new object() is bad, how come we inject the implementation and not the interface? I think a lot of you are saying we’re in fact injecting the interface but the configuration makes you specify the implementation of that interface ..not at runtime .. it is hardcoded during compile time.

This is based on the answer @Adam N posted.

Why does PersonService no longer have to worry about GroupMembershipService? You just mentioned GroupMembership has multiple things(objects/properties) it depends on. If GMService was required in PService, you’d have it as a property. You can mock that out regardless of whether you injected it or not. The only time I’d like it to be injected is if GMService had more specific child classs, which you wouldn’t know until runtime. Then you’d want to inject the subclass. Or if you wanted to use that as either singleton or prototype. To be honest, the configuration file has everything hardcoded as far as what subclass for a type (interface) it is going to inject during compile time.

EDITAR

A nice comment by Jose Maria Arranz on DI

DI increases cohesion by removing any need to determine the direction of dependency and write any glue code.

False. The direction of dependencies is in XML form or as annotations, your dependencies are written as XML code and annotations. XML and annotations ARE source code.

DI reduces coupling by making all of your components modular (ie replacable) and have well-defined interfaces to each other.

False. You do not need a DI framework to build a modular code based on interfaces.

About replaceable: with a very simple .properties archive and Class.forName you can define wich classs can change. If ANY class of your code can be changed, Java is not for you, use an scripting language. By the way: annotations cannot be changed without recompiling.

In my opinion there is one only reason for DI frameworks: boiler plate reduction. With a well done factory system you can do the same, more controlled and more predictable as your preferred DI framework, DI frameworks promise code reduction (XML and annotations are source code too). The problem is this boiler plate reduction is just real in very very simple cases (one instance-per class and similar), sometimes in the real world picking the appropriated service object is not as easy as mapping a class to a singleton object.

Dependency Injection means a way (actually any-way ) for one part of code (eg a class) to have access to dependencies (other parts of code, eg other classs, it depends upon) in a modular way without them being hardcoded (so they can change or be overriden freely, or even be loaded at another time, as needed)

(and ps , yes it has become an overly-hyped 25$ name for a rather simple, concept) , my .25 cents

I know there are already many answers, but I found this very helpful: http://tutorials.jenkov.com/dependency-injection/index.html

No Dependency:

 public class MyDao { protected DataSource dataSource = new DataSourceImpl("driver", "url", "user", "password"); //data access methods... public Person readPerson(int primaryKey) {...} } 

Dependency:

 public class MyDao { protected DataSource dataSource = null; public MyDao(String driver, String url, String user, String password){ this.dataSource = new DataSourceImpl(driver, url, user, password); } //data access methods... public Person readPerson(int primaryKey) {...} } 

Notice how the DataSourceImpl instantiation is moved into a constructor. The constructor takes four parameters which are the four values needed by the DataSourceImpl . Though the MyDao class still depends on these four values, it no longer satisfies these dependencies itself. They are provided by whatever class creating a MyDao instance.

The popular answers are unhelpful, because they define dependency injection in a way that isn’t useful. Let’s agree that by “dependency” we mean some pre-existing other object that our object X needs. But we don’t say we’re doing “dependency injection” when we say

 $foo = Foo->new($bar); 

We just call that passing parameters into the constructor. We’ve been doing that regularly ever since constructors were invented.

“Dependency injection” is considered a type of “inversion of control”, which means that some logic is taken out of the caller. That isn’t the case when the caller passes in parameters, so if that were DI, DI would not imply inversion of control.

DI means there is an intermediate level between the caller and the constructor which manages dependencies. A Makefile is a simple example of dependency injection. The “caller” is the person typing “make bar” on the command line, and the “constructor” is the compiler. The Makefile specifies that bar depends on foo, and it does a

 gcc -c foo.cpp; gcc -c bar.cpp 

before doing a

 gcc foo.o bar.o -o bar 

The person typing “make bar” doesn’t need to know that bar depends on foo. The dependency was injected between “make bar” and gcc.

The main purpose of the intermediate level is not just to pass in the dependencies to the constructor, but to list all the dependencies in just one place , and to hide them from the coder (not to make the coder provide them).

Usually the intermediate level provides factories for the constructed objects, which must provide a role that each requested object type must satisfy. That’s because by having an intermediate level that hides the details of construction, you’ve already incurred the abstraction penalty imposed by factories, so you might as well use factories.

Dependency injection is one possible solution to what could generally be termed the “Dependency Obfuscation” requirement. Dependency Obfuscation is a method of taking the ‘obvious’ nature out of the process of providing a dependency to a class that requires it and therefore obfuscating, in some way, the provision of said dependency to said class. This is not necessarily a bad thing. In fact, by obfuscating the manner by which a dependency is provided to a class then something outside the class is responsible for creating the dependency which means, in various scenarios, a different implementation of the dependency can be supplied to the class without making any changes to the class. This is great for switching between production and testing modes (eg., using a ‘mock’ service dependency).

Unfortunately the bad part is that some people have assumed you need a specialized framework to do dependency obfuscation and that you are somehow a ‘lesser’ programmer if you choose not to use a particular framework to do it. Another, extremely disturbing myth, believed by many, is that dependency injection is the only way of achieving dependency obfuscation. This is demonstrably and historically and obviously 100% wrong but you will have trouble convincing some people that there are alternatives to dependency injection for your dependency obfuscation requirements.

Programmers have understood the dependency obfuscation requirement for years and many alternative solutions have evolved both before and after dependency injection was conceived. There are Factory patterns but there are also many options using ThreadLocal where no injection to a particular instance is needed – the dependency is effectively injected into the thread which has the benefit of making the object available (via convenience static getter methods) to any class that requires it without having to add annotations to the classs that require it and set up intricate XML ‘glue’ to make it happen. When your dependencies are required for persistence (JPA/JDO or whatever) it allows you to achieve ‘tranaparent persistence’ much easier and with domain model and business model classs made up purely of POJOs (ie no framework specific/locked in annotations).

From the Book, ‘ Well-Grounded Java Developer: Vital techniques of Java 7 and polyglot programming

DI is a particular form of IoC, whereby the process of finding your dependencies is outside the direct control of your currently executing code.

from Book Apress.Spring.Persistence.with.Hibernate.Oct.2010

The purpose of dependency injection is to decouple the work of resolving external software components from your application business logic.Without dependency injection, the details of how a component accesses required services can get muddled in with the component’s code. This not only increases the potential for errors, adds code bloat, and magnifies maintenance complexities; it couples components together more closely, making it difficult to modify dependencies when refactoring or testing.

Dependency Injection (DI) is one from Design Patterns, which uses the basic feature of OOP – the relationship in one object with another object. While inheritance inherits one object to do more complex and specific another object, relationship or association simply creates a pointer to another object from one object using attribute. The power of DI is in combination with other features of OOP as are interfaces and hiding code. Suppose, we have a customer (subscriber) in the library, which can borrow only one book for simplicity.

Interface of book:

 package com.deepam.hidden; public interface BookInterface { public BookInterface setHeight(int height); public BookInterface setPages(int pages); public int getHeight(); public int getPages(); public String toString(); } 

Next we can have many kind of books; one of type is fiction:

 package com.deepam.hidden; public class FictionBook implements BookInterface { int height = 0; // height in cm int pages = 0; // number of pages /** constructor */ public FictionBook() { // TODO Auto-generated constructor stub } @Override public FictionBook setHeight(int height) { this.height = height; return this; } @Override public FictionBook setPages(int pages) { this.pages = pages; return this; } @Override public int getHeight() { // TODO Auto-generated method stub return height; } @Override public int getPages() { // TODO Auto-generated method stub return pages; } @Override public String toString(){ return ("height: " + height + ", " + "pages: " + pages); } } 

Now subscriber can have association to the book:

 package com.deepam.hidden; import java.lang.reflect.Constructor; import java.lang.reflect.InvocationTargetException; public class Subscriber { BookInterface book; /** constructor*/ public Subscriber() { // TODO Auto-generated constructor stub } // injection I public void setBook(BookInterface book) { this.book = book; } // injection II public BookInterface setBook(String bookName) { try { Class< ?> cl = Class.forName(bookName); Constructor< ?> constructor = cl.getConstructor(); // use it for parameters in constructor BookInterface book = (BookInterface) constructor.newInstance(); //book = (BookInterface) Class.forName(bookName).newInstance(); } catch (InstantiationException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } catch (ClassNotFoundException e) { e.printStackTrace(); } catch (NoSuchMethodException e) { e.printStackTrace(); } catch (SecurityException e) { e.printStackTrace(); } catch (IllegalArgumentException e) { e.printStackTrace(); } catch (InvocationTargetException e) { e.printStackTrace(); } return book; } public BookInterface getBook() { return book; } public static void main(String[] args) { } } 

All the three classs can be hidden for it’s own implementation. Now we can use this code for DI:

 package com.deepam.implement; import com.deepam.hidden.Subscriber; import com.deepam.hidden.FictionBook; public class CallHiddenImplBook { public CallHiddenImplBook() { // TODO Auto-generated constructor stub } public void doIt() { Subscriber ab = new Subscriber(); // injection I FictionBook bookI = new FictionBook(); bookI.setHeight(30); // cm bookI.setPages(250); ab.setBook(bookI); // inject System.out.println("injection I " + ab.getBook().toString()); // injection II FictionBook bookII = ((FictionBook) ab.setBook("com.deepam.hidden.FictionBook")).setHeight(5).setPages(108); // inject and set System.out.println("injection II " + ab.getBook().toString()); } public static void main(String[] args) { CallHiddenImplBook kh = new CallHiddenImplBook(); kh.doIt(); } } 

There are many different ways how to use dependency injection. It is possible to combine it with Singleton, etc., but still in basic it is only association realized by creating attribute of object type inside another object. The usefulness is only and only in feature, that code, which we should write again and again is always prepared and done for us forward. This is why DI so closely binded with Inversion of Control (IoC) which means, that our program passes control another running module, which does injections of beans to our code. (Each object, which can be injected can be signed or considered as a Bean.) For example in Spring it is done by creating and initialization ApplicationContext container, which does this work for us. We simply in our code create the Context and invoke initialization the beans. In that moment injection has been done automatically.

Example, we have 2 class Client and Service . Client will use Service

 public class Service { public void doSomeThingInService() { // ... } } 

Without Dependency Injection

Way 1)

 public class Client { public void doSomeThingInClient() { Service service = new Service(); service.doSomeThingInService(); } } 

Way 2)

 public class Client { Service service = new Service(); public void doSomeThingInClient() { service.doSomeThingInService(); } } 

Way 3)

 public class Client { Service service; public Client() { service = new Service(); } public void doSomeThingInClient() { service.doSomeThingInService(); } } 

1) 2) 3) Using

 Client client = new Client(); client.doSomeThingInService(); 

Advantages

  • Simples

Disadvantages

  • Hard for test Client class
  • When we change Service constructor, we need to change code in all place create Service object

Use Dependency Injection

Way 1) Constructor injection

 public class Client { Service service; Client(Service service) { this.service = service; } // Example Client has 2 dependency // Client(Service service, IDatabas database) { // this.service = service; // this.database = database; // } public void doSomeThingInClient() { service.doSomeThingInService(); } } 

Using

 Client client = new Client(new Service()); // Client client = new Client(new Service(), new SqliteDatabase()); client.doSomeThingInClient(); 

Way 2) Setter injection

 public class Client { Service service; public void setService(Service service) { this.service = service; } public void doSomeThingInClient() { service.doSomeThingInService(); } } 

Using

 Client client = new Client(); client.setService(new Service()); client.doSomeThingInClient(); 

Way 3) Interface injection

Check https://en.wikipedia.org/wiki/Dependency_injection

===

Now, this code is already follow Dependency Injection and it is easier for test Client class.
However, we still use new Service() many time and it is not good when change Service constructor. To prevent it, we can use DI injector like
1) Simple manual Injector

 public class Injector { public static Service provideService(){ return new Service(); } public static IDatabase provideDatatBase(){ return new SqliteDatabase(); } public static ObjectA provideObjectA(){ return new ObjectA(provideService(...)); } } 

Using

 Service service = Injector.provideService(); 

2) Use library: For Android dagger2

Advantages

  • Make test easier
  • When you change the Service , you only need to change it in Injector class
  • If you use use Constructor Injection , when you look at constructor of Client , you will see how many dependency of Client class

Disadvantages

  • If you use use Constructor Injection , the Service object is created when Client created, sometime we use function in Client class without use Service so created Service is wasted

Dependency Injection definition

https://en.wikipedia.org/wiki/Dependency_injection

A dependency is an object that can be used ( Service )
An injection is the passing of a dependency ( Service ) to a dependent object ( Client ) that would use it

In simple words dependency injection (DI) is the way to remove dependencies or tight coupling between different object. Dependency Injection gives a cohesive behavior to each object.

DI is the implementation of IOC principal of Spring which says “Don’t call us we will call you”. Using dependency injection programmer doesn’t need to create object using the new keyword.

Objects are once loaded in Spring container and then we reuse them whenever we need them by fetching those objects from Spring container using getBean(String beanName) method.

Dependency injection is the heart of the concept related with Spring Framework.While creating the framework of any project spring may perform a vital role,and here dependency injection come in pitcher.

Actually,Suppose in java you created two different classs as class A and class B, and whatever the function are available in class B you want to use in class A, So at that time dependency injection can be used. where you can crate object of one class in other,in the same way you can inject an entire class in another class to make it accessible. by this way dependency can be overcome.

DEPENDENCY INJECTION IS SIMPLY GLUING TWO CLASSES AND AT THE SAME TIME KEEPING THEM SEPARATE.

Dependency Injection (DI) is part of Dependency Inversion Principle (DIP) practice, which is also called Inversion of Control (IoC). Basically you need to do DIP because you want to make your code more modular and unit testable, instead of just one monolithic system. So you start identifying parts of the code that can be separated from the class and abstracted away. Now the implementation of the abstraction need to be injected from outside of the class. Normally this can be done via constructor. So you create a constructor that accepts the abstraction as a parameter, and this is called dependency injection (via constructor). For more explanation about DIP, DI, and IoC container you can read Here

Dependency Injection is a type of implementation of the ” Inversion of Control ” principle on which is based Frameworks building.

Frameworks as stated in “Design Pattern” of GoF are classs that implement the main control flow logic raising the developer to do that, in this way Frameworks realize the inversion of control principle.

A way to implement as a technique, and not as class hierarchy, this IoC principle it is just Dependency Injection.

DI consists mainly into delegate the mapping of classs instances and type reference to that instances, to an external “entity”: an object, static class, component, framework, etc…

Classes instances are the ” dependencies “, the external binding of the calling component with the class instance through the reference it is the ” injection “.

Obviously you can implement this technique in many way as you want from OOP point of view, see for example constructor injection , setter injection , interface injection .

Delegating a third party to carry out the task of match a ref to an object it is very useful when you want to completely separate a component that needs some services from the same services implementation.

In this way, when designing components, you can focus exclusively on their architecture and their specific logic, trusting on interfaces for collaborating with other objects without worry about any type of implementation changes of objects/services used, also if the same object you are using will be totally replaced (obviously respecting the interface).

Here is a great example explanation of dependency injections:

Guice docs