Qual é a injeção de dependência?

StackOverflow https://stackoverflow.com/questions/130794

Pergunta

Tem havido várias questões já postados com perguntas específicas sobre injeção de dependência , como quando a usá-lo e que os quadros estão lá para isso. No entanto,

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

Foi útil?

Solução

Dependency Injection está passando dependência para outra objetos ou framework (injetor de dependência).

Injeção de dependência facilita o teste. A injecção pode ser feito através de construtor .

SomeClass() tem seu construtor como a seguir: 

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

Problema : Se myObject envolve tarefas complexas, como o acesso ao disco ou o acesso à rede, é duro para fazer teste de unidade em SomeClass(). Os programadores têm de myObject simulada e poder interceptação a chamada fábrica.

Solução Alternativa :

  • Passando myObject como um argumento para o construtor 
public SomeClass (MyClass myObject) {
    this.myObject = myObject;
}

myObject pode ser passado diretamente que faz o teste mais fácil.

  • Uma alternativa comum é a definição de um não fazer nada construtor . Injeção de dependência pode ser feito através de setters. (H / t @MikeVella).
  • documentos Martin Fowler uma terceira alternativa (h / t @MarcDix), onde < strong> classes implementam explicitamente uma interface para as dependências programadores desejo injetados.

É mais difícil de isolar componentes na unidade de teste sem injecção de dependência.

Em 2013, quando eu escrevi esta resposta, este foi um tema importante na de testes do Google Blog . Continua a ser a maior vantagem para mim, como programadores nem sempre precisam de flexibilidade adicional na sua concepção de tempo de execução (por exemplo, para o localizador de serviço ou padrões semelhantes). Os programadores muitas vezes precisam de isolar as classes durante os testes.

Outras dicas

A melhor definição que eu encontrei até agora é um por James Shore :

"Dependency Injection" fica a 25 dólares termo para um conceito de 5 centavos. [...] Dependência meios de injecção dando um objeto suas variáveis ??de instância. [...].

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

Dependência injecção é basicamente proporcionar os objectos que um objecto (necessidades suas dependências) em vez de ter que construir-los em si. É uma técnica muito útil para testes, uma vez que permite dependências de ser ridicularizado ou apagou.

Dependências pode ser injectado em objectos por diversos meios (por exemplo, injecção ou injecção construtor Setter). Pode-se ainda utilizar os quadros de injeção de dependência especializados (por exemplo Primavera) para fazer isso, mas eles certamente não são necessários. Você não precisa esses quadros para ter injeção de dependência. Instanciar e passando objetos (dependências) explicitamente é tão bom como uma injeção de injeção por quadro.

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

Qualquer aplicativo é composto de muitos objetos que colaboram uns com os outros para executar algumas coisas úteis. Tradicionalmente, cada objecto é responsável por obter as suas próprias referências aos objetos dependentes (dependências) que colaboram com. Isto leva a classes fortemente acopladas e código de difícil teste.

Por exemplo, considere um objeto Car.

A Car depende rodas, motor, combustível, bateria, etc. para ser executado. Tradicionalmente, defina a marca desses objetos dependentes, juntamente com a definição do objeto Car.

Sem Dependency Injection (DI): 

class Car{
  private Wheel wh = new NepaliRubberWheel();
  private Battery bt = new ExcideBattery();

  //The rest
}

Aqui, o objeto Car é responsável por criar os objetos dependentes.

E se queremos mudar o tipo de seu objeto dependente - digamos Wheel - após as perfurações NepaliRubberWheel() iniciais? Precisamos recriar o objeto de carro com seu novo ChineseRubberWheel() dependência digamos, mas apenas o fabricante Car pode fazer isso.

Então, o que o Dependency Injection fazer-nos para ...?

Ao usar injeção de dependência, os objetos são dadas as suas dependências em tempo de execução em vez de tempo de compilação (fabricação de automóveis tempo) . Para que possamos agora mudar o Wheel sempre que queremos. Aqui, o dependency (wheel) pode ser injetado em Car em tempo de execução.

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

Aqui, nós somos injecção dependências (Roda e bateria) em tempo de execução. Daí o termo:. Dependency Injection 

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: dependência Entendimento injeção

Dependency Injection é uma prática onde os objetos são concebidos de uma forma onde recebem instâncias dos objetos de outros pedaços de código, em vez de construí-los internamente. Isto significa que qualquer objecto de execução a interface que é exigido pelo objecto pode ser substituído em sem alterar o código, o qual 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, a fim de fazer o seu trabalho. Sem Dependency Injection, a forma tradicional de fazer isso seria para instanciar um novo GroupMembershipService no construtor de PersonService e usar esse atributo de instância em ambas as funções. No entanto, se o construtor de GroupMembershipService tem várias coisas de que necessita, ou pior ainda, há algumas inicialização "setters" que precisam ser chamados no GroupMembershipService, o código cresce muito rapidamente, eo PersonService agora depende não só na GroupMembershipService mas também tudo o mais que GroupMembershipService depende. Além disso, a ligação para GroupMembershipService é codificado no PersonService o que significa que você não pode "fictício" um GroupMembershipService para fins de teste, ou usar um padrão de estratégia em diferentes partes de sua aplicação.

Com Dependency Injection, em vez de instanciar o GroupMembershipService dentro do seu PersonService, você quer passá-lo para o construtor PersonService, ou então adicionar uma propriedade (getter e setter) para definir uma instância local do mesmo. Isso significa que seu PersonService já não tem de se preocupar sobre como criar um GroupMembershipService, ele só aceita os que é dado, e trabalha com eles. Isto também significa que qualquer coisa que é uma subclasse de GroupMembershipService, ou implementa a interface GroupMembershipService pode ser "injetada" no PersonService, eo PersonService não precisa de saber sobre a mudança.

A resposta aceita é um bom - mas eu gostaria de acrescentar a isto que DI é muito parecido com o clássico evitando de constantes hardcoded no código.

Quando você usa alguma constante como um nome de banco de dados que você movê-lo rapidamente de dentro do código para algum arquivo de configuração e passar uma variável que contém esse valor para o lugar onde ela é necessária. A razão para isso é que essas constantes costumam mudar com mais freqüência do que o resto do código. Por exemplo, se você gostaria de testar o código em um banco de dados de teste.

DI é análogo a isso no mundo da programação orientada a objeto. Os valores lá em vez de literais constantes são objetos inteiros -, mas a razão para mover o código de criá-los para fora do código de classe é similar - os objetos mudar com mais freqüência, em seguida, o código que usa-los. Um caso importante, onde é necessária uma tal mudança é testes.

Vamos exemplo try simples com Car e Motor aulas, qualquer necessidade carro um motor para ir em qualquer lugar, pelo menos por agora. Portanto, a seguir 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 classe Car usaremos próximo código: 

Car car = new Car();

O problema com este código que nós firmemente acoplado ao GasEngine e se decidir alterá-lo para ElectricityEngine então vamos precisar reescrever classe Car. E quanto maior a aplicação dos mais problemas e dor de cabeça, teremos de adicionar e usar novo tipo de motor.

Em outras palavras, com esta abordagem é que o nosso elevado nível de classe Car depende da classe de nível GasEngine menor que violam inversão de dependência Princípio (DIP) de sólidos. DIP sugere que deveríamos depender de abstrações, e não classes concretas. Então, para satisfazer esta introduzimos interface de IEngine e código de reescrita 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, a nossa classe Car depende apenas a interface IEngine, não uma implementação específica do motor. Agora, o único truque é como podemos criar uma instância do carro e dar-lhe uma classe concreta Motor real como GasEngine ou ElectricityEngine. É onde Dependency Injection entra. 

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

Aqui nós basicamente injete (passe) a nossa dependência (instância Engine) para o construtor do carro. Então agora nossas aulas têm baixo acoplamento entre objetos e suas dependências, e podemos facilmente adicionar novos tipos de motores sem alterar a classe Car.

O principal benefício do Dependency Injection que as classes são mais fracamente acoplada, porque eles não têm dependências codificados. Isto segue o princípio de inversão de dependência, o que foi mencionado acima. Em vez de fazer referência a implementações específicas, aulas de solicitar abstrações (geralmente Interfaces ), que são fornecidos a eles quando a classe é construído.

Assim, no final injeção de dependência é apenas uma técnica para alcançar o fraco acoplamento entre objetos e suas dependências. Em vez de instanciar diretamente dependências que classe precisa em Para desempenhar as suas acções, as dependências são fornecidos para a classe (Mais frequentemente) via injeção de construtor.

Além disso, quando temos muitas dependências é muito boa prática para usar recipientes de inversão de controle (COI) que nós podemos dizer que as interfaces devem ser mapeados para que implementações concretas para todas as nossas dependências e podemos tê-lo resolver essas dependências para nós quando se constrói nosso objeto. Por exemplo, poderíamos especificar no mapeamento para o contêiner IoC que o IEngine dependência deve ser mapeado para o GasEngine classe e quando pedimos o contêiner IoC para uma instância do nosso Car classe, ele vai construir automaticamente nosso Car classe com um GasEngine dependência passado.

UPDATE:. Assistidos curso sobre EF Core a partir de Julie Lerman recentemente e também gostava dela breve definição sobre DI

Injeção de dependência é um padrão para permitir que seu aplicativo para injetar objetos em tempo real para as classes que precisam deles, sem forçar os classes para ser responsável por esses objetos. Ele permite que seu código seja mais baixo acoplamento, e Entity Framework Core conecta a esse mesmo sistema de serviços.

imaginar que você quer ir pesca Let:

  • Sem injeção de dependência, você precisa cuidar de tudo sozinho. Você precisa encontrar um barco, para comprar uma vara de pesca, a olhar para a isca, etc. É possível, é claro, mas ele coloca muita responsabilidade sobre você. Em termos de software, isso significa que você tem que realizar uma pesquisa por todas estas coisas.

  • Com a injeção de dependência, alguém cuida de toda a preparação e torna os equipamentos necessários disponíveis para você. Você receberá ( "ser injetado") o barco, a vara de pescar e isca -. Tudo pronto para uso

Este é a explicação mais simples sobre Dependency Injection e Dependency Injection Container que eu já vi:

Sem Dependency Injection

  • A aplicação necessita Foo (por exemplo, um controlador), assim:
  • Aplicação cria Foo
  • aplicativo chama Foo
    • Foo precisa Bar (por exemplo, um serviço), assim:
    • Foo cria Bar
    • Foo chama Bar
      • Bar precisa Bim (um serviço, um repositório, ...), assim:
      • Bar cria Bim
      • Bar faz algo

Com Dependency Injection

  • Aplicação precisa de Foo, que precisa Bar, que precisa Bim, assim:
  • Aplicação cria Bim
  • Aplicação cria Bar e dá-lhe Bim
  • Aplicação cria Foo e dá-lhe Bar
  • aplicativo chama Foo
    • Foo chama Bar
      • Bar faz algo

Usando um Dependency Injection Container

  • Aplicação precisa Foo assim:
  • Aplicação recebe Foo do Container, então:
    • Container cria Bim
    • Container cria Bar e dá-lhe Bim
    • Container cria Foo e dá-lhe Bar
  • aplicativo chama Foo
    • Foo chama Bar
      • Bar faz algo

Dependency Injection e injeção de dependência Containers são coisas diferentes:

  • Dependency Injection é um método para escrever código melhor
  • a DI Container é uma ferramenta para ajudar a injetar dependências

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

não "injeção de dependência" significa apenas usando construtores parametrizados e setters públicos?

artigo mostra de James Shore 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 já foi dito, Dependency Injection (DI) remove a responsabilidade da criação direta e gestão do ciclo de vida, de outras instâncias do objeto sobre o qual nossa classe de interesse (classe de consumidores) é dependente ( no UML sentido ). Essas instâncias são em vez passado para a nossa classe de consumidores, tipicamente como parâmetros do construtor ou via setters de propriedade (a gestão do objeto de dependência instanciação e passando para a classe de consumo é geralmente realizada por um Inversão de Controle (IoC) recipiente, mas isso é outro assunto).

DI, DIP e SOLID

Especificamente, no paradigma da princípios sólidos de Robert C Martin de Object Oriented Design , DI é uma das possíveis implementações do inversão de dependência Princípio (DIP) . O DIP é o D do SOLID mantra -. Outras implementações DIP incluem o Locator Service, e os padrões Plugin

O objetivo do DIP é dissociar apertado, dependências de concreto entre as classes, e em vez disso, para afrouxar o acoplamento por meio de uma abstração, o que pode ser alcançado através de uma interface, abstract class ou pure virtual class, dependendo da linguagem e abordagem utilizada .

Sem o DIP, o nosso código (eu chamei este 'consumir class') está diretamente acoplado a uma dependência concreto e também é muitas vezes sobrecarregados 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, a exigência é solta, e a preocupação de obter e gerenciar o ciclo de vida da dependência Foo foi removido: 

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

Por que usar DIP (e DI)?

A dissociação dependências entre as classes desta forma permite a substituição fácil uma dessas classes de dependência com outras implementações que também preencham os pré-requisitos da abstração (por exemplo, a dependência pode ser alternado com outra implementação da mesma interface ). Além disso, como já foi mencionado, possivelmente o razão mais comum para as classes dissociar através do DIP é permitir que uma classe consumir a ser testado isoladamente, uma vez que estas mesmas dependências podem agora ser arrancado e / ou ridicularizado.

Uma consequência de DI é que o tempo de vida de gestão de objectos casos de dependência não é controlado por uma classe de consumir, como o objecto de dependência é agora passada para a classe consumir (via construtor ou injecção Setter).

Isto pode ser visto de diferentes maneiras:

  • Se o controle de tempo de vida de dependências pelas consumidoras necessidades da classe a ser retido, o controle pode ser re-estabelecida pela injeção de uma fábrica (resumo) para criar as instâncias de classe dependência, na classe de consumo. O consumidor será capaz de obter instâncias através de uma Create na fábrica, conforme necessário, e dispor desses casos, uma vez concluída.
  • Ou, o controlo de casos de dependência vida útil pode ser abandonado para um recipiente COI (mais sobre este abaixo).

Quando usar DI?

  • Onde provavelmente haverá uma necessidade de substituir uma dependência para uma implementação equivalente,
  • A qualquer momento em que você vai precisar para teste de unidade os métodos de uma classe isoladamente de suas dependências,
  • Onde incerteza do tempo de vida de uma dependência podem justificar a experimentação (por exemplo Hey, MyDepClass é segmento seguro - e se nós torná-lo um singletone injetar a mesma instância para todos os consumidores?)

Exemplo

Aqui está uma implementação simples C #. Dada a seguir classe consumidora: 

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 dependências static em duas outras classes, System.DateTime e System.Console, que não só limitam as opções de saída de log (registro para console será inútil se ninguém está olhando), mas pior, é difícil automaticamente teste dado a dependência de um relógio do sistema não-determinista.

No entanto, podemos aplicar DIP a esta classe, abstraindo a preocupação de timestamping como uma dependência, e acoplamento MyLogger apenas para uma interface simples: 

public interface IClock
{
    DateTime Now { get; }
}

Também pode afrouxar a dependência Console a uma abstração, como uma TextWriter. Dependency Injection é tipicamente implementado como qualquer injeção constructor (passando uma abstração a uma dependência como um parâmetro para o construtor de uma classe que consome) ou Setter Injection (passando a dependência através de um setter setXyz() ou uma propriedade .Net com {set;} definido). Injecção construtor é preferido, que esta garante a classe vai estar num estado correcto após a construção, e permite que os campos de dependência internas a ser marcado como readonly (C #) ou final (Java). Então, usando injeção de construtor no exemplo acima, isso deixa-nos 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);
    }
}

(necessidades concreto Clock à ser fornecido, o que evidentemente pode reverter para DateTime.Now, e as duas dependências precisa ser fornecida por um recipiente COI via injecção construtor)

Uma unidade de teste automatizado pode ser construída, o que prova definitivamente que a nossa logger está funcionando corretamente, já que agora temos controle sobre as dependências - o tempo, e podemos espionar a saída escrita: 

[Test]
public void LoggingMustRecordAllInformationAndStampTheTime()
{
    // Arrange
    var mockClock = new Mock<IClock>();
    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óximas etapas

Dependência injecção está invariavelmente associada com uma inversão do recipiente de controlo (COI) , para injectar ( fornecer) os casos de dependência de concreto, e para gerenciar instâncias vida útil. Durante o processo de configuração / bootstrapping, recipientes IoC permitir que o que se segue para ser definido:

  • mapeamento entre cada abstracção e a implementação concreta configurado (por exemplo, "a qualquer momento um consumidor solicita uma IBar, devolva um exemplo ConcreteBar" )
  • políticas pode ser configurado para a gestão tempo de vida de cada dependência, por exemplo, para criar um novo objeto para cada instância do consumidor, para compartilhar uma instância singleton dependência em todos os consumidores, para compartilhar a mesma instância dependência só através do mesmo segmento, etc.
  • Na Net, recipientes de IoC estão cientes de protocolos como IDisposable e vai assumir a responsabilidade de dependências Disposing em linha com a gestão de vida útil configurado.

Normalmente, uma vez que os recipientes de IoC foram configurados / bootstrap, eles operam perfeitamente no fundo permitindo que o codificador para focar o código à mão em vez de se preocupar com dependências.

A chave para o código DI-friendly é evitar acoplamento estática das classes, e não usar new () para a criação de dependências

Como por exemplo acima, a dissociação de dependências exige algum esforço de design, e para o desenvolvedor, há uma mudança de paradigma necessária para quebrar o hábito de newing dependências diretamente e, em vez de confiar o recipiente para gerenciar dependências.

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

Nota : A criação / mapeamento / projecção (via new ..()) de Poço / POprojecções JO / serialização DTO / Entidade Gráficos / Anonymous JSON et ai - isto é, "dados só" classes ou registos - utilizados ou devolvidos a partir de métodos são não considerado como dependências (no sentido UML) e não sujeito a DI. Usando new para projetar estes é apenas multa.

Para fazer o conceito Dependency Injection simples de entender. Vamos dar um exemplo de botão interruptor para alternar (on / off) uma lâmpada.

Sem Dependency Injection

Mudar precisa saber de antemão qual lâmpada estou ligado a (dependência hard-coded). Então,

Switch -> PermanentBulb // interruptor está diretamente ligado à lâmpada permanente, testando não é possível facilmente 

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

Com Dependency Injection

Mudar só sabe que eu preciso para ligar / desligar qualquer Bulb é passado para mim. Então,

Switch -> Bulb1 OU Bulb2 OU NightBulb (dependência injetado) 

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

James Exemplo de Switch e lâmpada: 

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(); 
    ... 
  } 
}`

O ponto inteiro de Dependency Injection (DI) é manter código fonte da aplicação limpa e estável :

  • limpa de código de inicialização dependência
  • estável , independentemente de dependência usado

Na prática, cada padrão de design separa preocupações para fazer alterações futuras afeta os arquivos mínimos.

O domínio específico do DI é delegação de configuração de dependência e inicialização.

Exemplo: DI com shell script

Se você ocasionalmente fora do trabalho de Java, recordar como source é frequentemente usado em muitas linguagens de script (Shell, Tcl, etc., ou mesmo import em Python mal utilizado para esta finalidade).

Considere roteiro dependent.sh simples: 

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

O script é dependente:. Não irá executar com sucesso por conta própria (archive_files não está definido)

Você define archive_files no roteiro implementação archive_files_zip.sh (usando zip neste caso): 

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

Em vez de source-ing roteiro de implementação diretamente no único dependente, você usa um injector.sh "container" que envolve ambos os "componentes": 

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

O archive_files dependência acaba de ser injetado em dependente script.

Você poderia ter injetado dependência que implementa archive_files usando tar ou xz.

Exemplo: remoção DI

Se o script dependent.sh dependências usado diretamente, a abordagem seria chamado dependência pesquisa (que fica em frente ao injeção de dependência ): 

#!/bin/sh
# Dependent

# dependency look-up
source ./archive_files_zip.sh

touch         "one.txt" "two.txt"
archive_files "one.txt" "two.txt"

Agora, o problema é que dependente "componente" tem que executar a inicialização em si.

O "componente" de código-fonte não é nem limpa nem estável porque cada mudanças na inicialização de dependências requer nova versão para 'componentes' 's arquivo de código fonte como bem.

Últimas palavras

DI não é tão largamente enfatizada e popularizado como em frameworks Java.

Mas é uma abordagem genérica às preocupações de divisão de:

  • aplicativo desenvolvimento ( única ciclo de vida do lançamento do código-fonte)
  • aplicação implantação (<> fortes múltiplos fortes ambientes alvo com ciclos de vida independentes)

Usando configuração apenas com dependência pesquisa não ajuda como o número de parâmetros de configuração podem mudar por dependência (por exemplo, novo tipo de autenticação), bem como número de tipos suportados de dependências (por exemplo, novo tipo de banco de dados).

Todas as respostas acima são boas, o meu objectivo é explicar o conceito de uma forma simples para que qualquer pessoa sem conhecimentos de programação também pode compreender o conceito

Injeção de dependência é um dos o padrão de design que nos ajudam a criar sistemas complexos de uma forma mais simples.

Podemos ver uma grande variedade de aplicação deste modelo em nosso dia-a-dia. Alguns dos exemplos são gravador de fita, VCD, CD drive etc.

gravador de bobina a bobina de fita portátil, mid-20th século.

A imagem acima é uma imagem do gravador portátil Reel-to-reel, meados do século 20. Fonte .

A intenção principal de uma máquina gravador é gravar ou som de reprodução.

Ao projetar um sistema que exigem um carretel para gravação ou reprodução de som ou música. Há duas possibilidades para a concepção deste sistema

  1. podemos colocar o carretel dentro da máquina
  2. nós podemos fornecer um gancho para o carretel, onde ele pode ser colocado.

Se usarmos o primeiro precisamos abrir o aparelho para mudar a bobina. se optar pela segunda, que é a colocação de um gancho para carretel, estamos recebendo um benefício adicional de jogar qualquer música mudando a bobina. e também reduzindo a função apenas para jogar o que quer na bobina.

Como injecção dependência sábio é o processo de externalização das dependências de se concentrar somente na funcionalidade específica do componente, de modo que os componentes independentes podem ser acoplados em conjunto para formar um sistema complexo.

Os principais benefícios que conseguimos usando a injeção de dependência.

  • alta coesão e baixo acoplamento.
  • A externalização dependência e olhando apenas na responsabilidade.
  • Fazer as coisas como componentes e combinar para formar uma grande sistemas com capacidades de altura.
  • Ajuda a desenvolver componentes de alta qualidade, uma vez que são desenvolvidos de forma independente que sejam devidamente testados.
  • Ela ajuda a substituir o componente por outro se um falhar.

Agora, um dia destes conceito forma a base de quadros bem conhecidos no mundo de programação. A Primavera Angular etc são os bem conhecidos estruturas de software construídas no topo deste conceito

Dependência injecção é um teste padrão usado para criar as instâncias de objectos que outros objectos dependem sem saber em tempo de compilação qual classe vai ser utilizado para prever que a funcionalidade ou simplesmente a forma de injecção de propriedades de um objecto é chamado injecção dependência.

Exemplo injectável Dependência

Anteriormente estamos escrevendo código como este 

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();
}

Com a injeção de dependência, o injector dependência vai decolar a instanciação para nós 

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();
}

Você também pode ler

Diferença entre Inversão de Controle e Dependency Injection

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

Dependência Injecção (DI) meios para desacoplar os objectos que são dependentes uns dos outros. Digamos objeto A é dependente de um objecto B de modo a ideia é dissociar estes objetos entre si. Nós não precisa codificar o objeto usando a nova palavra-chave, em vez compartilhando dependências a objetos em tempo de execução, apesar de tempo de compilação. Se falamos

Como a injeção de dependência obras em Primavera:

Nós não precisa codificar o objeto usando a nova palavra-chave, em vez definir a dependência feijão no arquivo de configuração. O recipiente primavera será responsável por ligar todos.

inversão de controle (COI)

COI é um conceito geral e que pode ser expressa de muitas maneiras diferentes e Dependency Injection é um exemplo concreto do COI.

Dois tipos de Dependency Injection:

  1. Constructor Injection
  2. Setter Injection

1. injeção de dependência baseada construtor:

Construtor-DI base é conseguido quando o recipiente invoca um construtor de classe com um número de argumentos, cada um representando uma dependência de outra classe. 

public class Triangle {

private String type;

public String getType(){
    return type;
 }

public Triangle(String type){   //constructor injection
    this.type=type;
 }
}
<bean id=triangle" class ="com.test.dependencyInjection.Triangle">
        <constructor-arg value="20"/>
  </bean>

2. injeção de dependência baseada Setter:

base-Setter DI é realizado pelo contêiner chamando métodos setter sobre o seu feijão depois de invocar um método de fábrica estático sem argumento construtor ou sem argumentos para instanciar seu bean. 

public class Triangle{

 private String type;

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

<!-- setter injection -->
 <bean id="triangle" class="com.test.dependencyInjection.Triangle">
        <property name="type" value="equivialteral"/>

NOTA: É uma boa regra de ouro para usar argumentos do construtor para dependências obrigatórias e setters para dependências opcionais. Note que o se usarmos anotação base de anotação @Required em um setter pode ser usado para fazer setters como um dependências necessárias.

A melhor analogia que posso pensar é o cirurgião e seu assistente (s) em uma sala de cirurgia, onde o cirurgião é a pessoa principal e seu assistente, que fornece os vários componentes cirúrgicos quando ele precisa dela para que o cirurgião possa se concentrar sobre a única coisa que ele faz melhor (cirurgia). Sem o assistente do cirurgião tem que obter os componentes si mesmo cada vez que ele precisa de um.

DI para breve, é uma técnica para remover uma responsabilidade adicional comum (carga) em componentes para buscar os componentes dependentes, proporcionando-lhes a ele.

DI traz para mais perto da Responsabilidade Individual (SR) princípio, como o surgeon who can concentrate on surgery.

Quando usar DI: Eu recomendaria usar DI em quase todos os projetos de produção (pequeno / grande), particularmente em ambientes de negócios em constante mudança:)

Por: Porque você quer que seu código seja facilmente testável, mockable etc para que você possa testar rapidamente as alterações e empurrá-lo para o mercado. Além de por que você não quando há muitas ferramentas gratuitas / frameworks impressionantes para apoiá-lo em sua jornada para uma base de código onde você tem mais controle.

Isso significa que os objetos só deve ter tantas dependências como é necessário para fazer o seu trabalho e as dependências devem ser poucos. Além disso, as dependências de um objeto deve ser em interfaces e não em objetos “concretas”, quando possível. (Um objeto concreto é qualquer objeto criado com a palavra-chave novo.) De acoplamento frouxo promove uma maior reutilização, manutenção mais fácil, e permite que você facilmente fornecer objetos “simulados” no lugar de serviços caros.

O “Injecção de dependência” (DI) também é conhecido como “inversão de controle” (COI), pode ser usado como uma técnica para encorajar esta acoplamento solto.

Existem duas abordagens principais para DI de execução:

  1. injeção de construtor
  2. injeção Setter

Construtor de injeção

É a técnica de passar objetos dependências para seu construtor.

Note que o construtor aceita um objeto concreto interface e não. Além disso, nota que uma exceção é lançada se o parâmetro orderDao é nulo. Isso enfatiza a importância de receber uma dependência válida. Construtor de injecção é de, em nossa opinião, o mecanismo preferido para dar a um objecto suas dependências. É claro para o desenvolvedor ao chamar o objeto que dependências precisam ser dado ao objeto “Pessoa” para execução adequada.

Setter Injection

Mas considere o seguinte exemplo ... Suponha que você tenha uma classe com métodos dez que não têm dependências, mas você está adicionando um novo método que tem uma dependência em IDAO. Você poderia mudar o construtor usar Constructor Injection, mas isso pode forçá-lo a mudanças em todas as chamadas do construtor em todo o lugar. Alternativamente, você pode simplesmente adicionar um novo construtor que leva a dependência, mas então como é que um desenvolvedor saber facilmente quando usar um construtor sobre o outro. Finalmente, se a dependência é muito caro para criar, por que deveria ser criado e passado para o construtor quando ele só pode ser utilizado raramente? “Injeção Setter” é outra técnica DI que pode ser usado em situações como esta.

Setter Injection não força dependências a serem passados ??para o construtor. Em vez disso, as dependências são definidas em propriedades públicas expostas pelo objeto em necessidade. Como está implícito anteriormente, os motivadores primários para fazer isso incluem:

  1. Apoio a injeção de dependência, sem ter que modificar o construtor de uma classe legado.
  2. permitindo que os recursos ou serviços caros a ser criado o mais tarde possível e somente quando necessário.

Aqui está o exemplo de como o código acima seria parecido com: 

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;

Exemplo, temos 2 Client classe e Service. Client usará Service 

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

Sem 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) Utilizando 

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

Vantagens

  • Simples

Desvantagens

  • rígido para classe de teste Client
  • Quando mudamos construtor Service, precisamos código de mudança em todos lugar criar o objeto Service

Use Dependency Injection

Way 1) injeção de construtor 

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();
    }
}

Usando 

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

Way 2) injeção Setter 

public class Client {
    Service service;

    public void setService(Service service) {
        this.service = service;
    }

    public void doSomeThingInClient() {
        service.doSomeThingInService();
    }
}

Usando 

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

Way 3) injeção de Interface

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

===

Agora, esse código é já seguem Dependency Injection e é mais fácil para a classe de teste Client.
No entanto, nós ainda usamos muitos tempo new Service() e não é bom quando construtor mudança Service. Para evitar isso, podemos usar DI injector como
1) manual simples 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(...));
    }
}

Usando 

Service service = Injector.provideService();

2) Use biblioteca: Para Android dagger2

Vantagens

  • teste de facilitar
  • Quando você altera o Service, você só precisa mudá-lo em sala de aula Injector
  • Se você usar uso Constructor Injection, quando você olha para o construtor de Client, você vai ver quantos dependência de classe Client

Desvantagens

  • Se você usar uso Constructor Injection, o objeto Service é criado quando Client criado, em algum momento usamos a função na classe Client sem uso Service tão Service criado é desperdiçado

definição Dependency Injection

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

A dependência é um objeto que pode ser usado (Service)
Uma injeção é a passagem de uma dependência (Service) para um objeto dependente (Client) que iria utilizá-lo

Eu acho que uma vez que todos tem escrito para DI, deixe-me fazer algumas perguntas ..

  1. Quando você tem uma configuração de DI, onde todas as implementações reais (não interfaces) que vão ser injetado em uma classe (por v.g. serviços a um controlador) por que é que não algum tipo de codificar?
  2. E se eu quiser mudar o objeto em tempo de execução? Por exemplo, minha configuração já diz quando eu instanciar MyController, injetar para FileLogger como ILogger. Mas eu poderia querer injetar DatabaseLogger.
  3. Toda vez que eu quiser mudar o que os objetos minhas necessidades Aclass, eu preciso olhar agora em dois lugares - A classe em si e o arquivo de configuração. Como o que a vida faz mais fácil?
  4. Se aProperty de AClass não é injetado, é mais difícil para zombar-lo?
  5. Voltando à primeira pergunta. Se estiver usando novo objeto () é ruim, como é que nós injetar a implementação e não a interface? Eu acho que muitos de vocês estão dizendo que estamos na verdade injetando a interface mas a configuração faz com que você especificar a implementação dessa ..não de interface em tempo de execução .. ele é codificado durante o tempo de compilação.

Esta é baseada na resposta @ Adam N postou.

Por que PersonService já não têm de se preocupar com GroupMembershipService? Você acabou de mencionar GroupMembership tem coisas múltiplas (objetos / propriedades) que depende. Se GMService foi necessária em PService, você tê-lo como uma propriedade. Você pode zombar isso, independentemente de você injetado ou não. A única vez que eu gostaria que ser injetado é se GMService tinha classes filho mais específicos, que você não saberia até que tempo de execução. Então você quer injetar a subclasse. Ou se você quiser usar isso como seja exclusivo ou protótipo. Para ser honesto, o arquivo de configuração tem tudo codificado, tanto quanto o subclasse para um tipo (interface) que vai injetar durante o tempo de compilação.

Editar

Um bom comentário por José Maria Arranz em DI

DI aumenta a coesão, removendo qualquer necessidade de determinar o sentido de dependência e escrever qualquer código cola.

False. A direção de dependências está em forma de XML ou como anotações, suas dependências são escritos como código XML e anotações. XML e anotações são código-fonte.

DI reduz o acoplamento, fazendo todos os seus componentes modulares (ou seja substituível) e têm interfaces bem definidas entre si.

False. Você não precisa de um quadro DI para construir um código modular baseado em interfaces.

Sobre substituíveis: com muito simples .properties arquivar e Class.forName você pode definir classes wich pode mudar. Se qualquer classe de seu código pode ser alterado, Java não é para você, use uma linguagem de script. A propósito: anotações não pode ser alterado sem recompilar

.

Na minha opinião há uma única razão para frameworks de DI: redução de placa de caldeira. Com um sistema de fábrica bem feito, você pode fazer o mesmo, mais controlado e mais previsível como o seu quadro DI preferido, estruturas DI prometem redução de código (XML e anotações são código-fonte também). O problema é essa redução placa de caldeira é apenas real em casos muito, muito simples (uma instância-per classe e similar), às vezes no mundo real escolher o objeto de serviço apropriado não é tão fácil como o mapeamento de uma classe para um objeto singleton.

Dependência meios uma forma (na verdade qualquer caminho ) para uma parte do código (por exemplo, uma classe) para ter acesso a dependências (outras partes do código, por exemplo, outras classes, que depende) de uma maneira modular, sem lhes ser codificado (para que possam alterar ou ser substituído livremente, ou até ser carregado numa outra altura, conforme necessário)

(e ps, sim, tornou-se um 25 $ name excessivamente sensacionalistas para um bastante simples, conceito) , meus centavos .25

Eu sei que existem já muitas respostas, mas eu achei isso muito útil: http: //tutorials.jenkov. com / dependência de injecção / index.html

Sem Dependência: 

public class MyDao {

  protected DataSource dataSource =
    new DataSourceImpl("driver", "url", "user", "password");

  //data access methods...
  public Person readPerson(int primaryKey) {...}

}

Dependência: 

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)
  {...}

}

Observe como a instanciação DataSourceImpl é movido para um construtor. O construtor tem quatro parâmetros que são os quatro valores necessários pelo DataSourceImpl. Embora a classe MyDao ainda depende desses quatro valores, satisfaz já não estas dependências em si. Eles são fornecidos por qualquer classe criando uma instância MyDao.

As respostas populares são inúteis, porque eles definem a injeção de dependência de uma forma que não é útil. Vamos concordar que por "dependência" queremos dizer algum outro objeto pré-existente que nossas necessidades objeto X. Mas nós não dizemos que estamos fazendo "injeção de dependência" quando dizemos 

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

Nós só chamar que os parâmetros passando para o construtor. Estamos fazendo isso regularmente desde então construtores foram inventadas.

"Injeção de dependência" é considerado um tipo de "inversão de controle", o que significa que alguma lógica é retirado do chamador. Isso não é o caso quando o chamador passa em parâmetros, por isso, se isso fosse DI, DI não implicaria inversão de controle.

DI significa que há um nível intermédio entre o chamador e o construtor que gere dependências. Um Makefile é um exemplo simples de injecção dependência. O "chamador" é a pessoa digitando "make bar" na linha de comando, e o "construtor" é o compilador. Os especifica makefile que bar depende foo, e ele faz um 

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

antes de fazer um 

gcc foo.o bar.o -o bar

A pessoa digitando "make bar" não precisa saber que bar depende foo. A dependência foi injetado entre "make bar" e gcc.

O principal objetivo do nível intermediário não é apenas para passar nas dependências para o construtor, mas para listar todas as dependências em apenas um lugar , e de escondê-los a partir do codificador (não fazer o codificador fornecê-los).

Normalmente, o nível intermediário fornece fábricas para os objetos construídos, que deve fornecer um papel que cada tipo de objeto solicitado deve satisfazer. Isso porque por ter um nível intermediário que esconde os detalhes de construção, você já incorreu na pena de abstração imposta por fábricas, de modo que você pode também usar fábricas.

Injeção de dependência é uma possível solução para o que poderia geralmente ser chamado a exigência "Dependência Obfuscation". Dependência Obfuscation é um método de tomar a natureza 'óbvio' para fora do processo de prestação de uma dependência a uma classe que exige isso e, portanto, ofuscando, de alguma forma, a prestação da referida dependência à referida classe. Isto não é necessariamente uma coisa ruim. Na verdade, por ofuscar a maneira pela qual uma dependência é fornecida para uma classe, em seguida, algo fora da classe é responsável por criar a dependência que significa, em vários cenários, uma implementação diferente da dependência pode ser fornecido para a classe sem fazer quaisquer alterações para a aula. Isto é grande para comutação entre a produção e teste de modos (por exemplo., Utilizando uma dependência de serviço 'simulada').

Infelizmente a parte ruim é que algumas pessoas têm assumido você precisa de uma estrutura especializada para fazer ofuscação dependência e que você é de alguma forma um programador de 'menor' se você optar por não usar uma estrutura particular para fazê-lo. Outra, mito extremamente preocupante, considerado por muitos, é que a injeção de dependência é a única maneira de alcançar a ofuscação dependência. Este é comprovadamente e historicamente e, obviamente, 100% errado, mas você vai ter problemas para convencer algumas pessoas de que existem alternativas para injeção de dependência para as suas necessidades de ofuscação de dependência.

Os programadores têm entendido a exigência ofuscação dependência por anos e muitas soluções alternativas têm evoluído tanto antes como após a injeção de dependência foi concebido. Existem padrões de fábrica, mas também há muitas opções usando ThreadLocal onde é necessária nenhuma injeção para uma instância particular - a dependência é efetivamente injetados na discussão que tem a vantagem de fazer o objeto disponível (através de métodos de conveniência estática getter) para qualquer classe que requer lo sem ter que adicionar anotações às classes que necessitam dele e montou intrincada XML 'cola' para que isso aconteça. Quando são necessárias suas dependências para a persistência (JPA / JDO ou qualquer outro) que lhe permite atingir 'tranaparent persistência' muito mais fácil e com o modelo de domínio e classes de modelo de negócios composta exclusivamente de POJOs (ou seja, nenhum quadro específico / trancado em anotações).

Do livro, ' bem fundamentada Java Developer: técnicas vitais de Java 7 e poliglota programação

DI é uma forma particular de IoC, em que o processo de encontrar suas dependências é fora do controle direto do seu código atualmente em execução.

do livro Apress.Spring.Persistence.with.Hibernate.Oct.2010

O objetivo da injeção de dependência é dissociar o trabalho de resolução de componentes de software externos de sua empresa aplicação injeção de dependência logic.Without, os detalhes de como um componente acessos serviços necessários podem ficar confusos com as do componente código. Isto não só aumenta o potencial de erros, adiciona código inchaço, e manutenção amplia complexidades; componentes de TI casais juntos mais de perto, o que torna difícil para modificar dependências quando refatoração ou teste.

Dependency Injection (DI) é um de Design Patterns, que usa o recurso básico de OOP - a relação em um objeto com outro objeto. Enquanto a herança herda um objecto para fazer mais complexo e específico outro objectivo, a relação ou associação simplesmente cria um ponteiro para um outro objecto de um objecto utilizando atributo. O poder de DI está em combinação com outras características do OOP como são interfaces e código de esconderijo. Suponha-se, nós temos um cliente (assinante) na biblioteca, que pode pedir apenas um livro pela simplicidade.

Interface do livro: 

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();
}

Em seguida, pode ter muitos tipos de livros; uma do tipo é ficção: 

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);
}
}

Agora assinante pode ter associação com o livro: 

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) {

}

}

Todas as três classes pode ser escondido para a sua própria implementação. Agora podemos usar este código para 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();
}
}

Existem muitas maneiras diferentes de como usar injeção de dependência. É possível combiná-lo com Singleton, etc., mas ainda em básica é única associação percebeu criando atributo do tipo de objeto dentro de outro objeto. A utilidade é apenas e só no recurso, que o código, que devemos escrever uma e outra vez é sempre preparado e feito por nós para a frente. É por isso DI tão intimamente binded com inversão de controle (COI) que os meios, que nossos passes programa de controlo de um outro módulo de execução, o que faz injecções de grãos para o nosso código. (Cada objeto, que pode ser injetado pode ser assinado ou considerado como um Bean.) Por exemplo, na Primavera é feito através da criação e inicialização ApplicationContext recipiente, o que faz este trabalho para nós. Nós simplesmente em nosso código criar o contexto e invocar a inicialização do feijão. Em que a injeção momento tem sido feito automaticamente.

simples injecção palavras dependência (DI) representa a forma de remover dependências ou acoplamento apertado entre diferente objecto. Dependency Injection dá um comportamento coeso a cada objeto.

DI é a implementação do IOC principal da Primavera, que diz: "Não ligue para nós que vai chamá-lo". Usando programador injeção de dependência não precisa criar o objeto usando a nova palavra-chave.

Os objectos são, uma vez carregado no recipiente de mola e, em seguida, reutilizá-los, sempre que precisa delas por buscar os objectos a partir do recipiente da mola usando o método getBean (String beanName).

Injeção de dependência é o coração do conceito relacionado com a Primavera Framework.While criação do quadro de qualquer primavera projeto pode desempenhar um papel vital, e aqui injeção de dependência venha no jarro.

Na verdade, Suponha que em Java você criou duas classes diferentes como classe A e classe B, e qualquer que seja a função estão disponíveis na classe B que deseja usar na classe A, de modo a que a injeção de dependência tempo pode ser usado. onde você pode objeto caixa de uma classe em outra, da mesma forma que você pode injetar uma classe inteira em outra classe para torná-lo acessível. desta forma a dependência pode ser superada.

injeção de dependência é simplesmente COLAGEM DUAS CLASSES E AO MESMO TEMPO QUE MANTEM-los separados.

Dependency Injection (DI) é parte de inversão de dependência Princípio (DIP) prática, que também é chamado de inversão de controle (COI). Basicamente, você precisa fazer DIP porque você quer tornar seu código mais modular e unidade testável, em vez de apenas um sistema monolítico. Então você começar a identificar partes do código que pode ser separada da classe e abstraída. Agora, a implementação da necessidade de abstração para ser injetada de fora da classe. Normalmente isso pode ser feito via construtor. Assim você cria um construtor que aceita a abstração como um parâmetro, e isso é chamado de injeção de dependência (via construtor). Para obter mais explicações sobre DIP, DI e contêiner IoC você pode ler Aqui

Gostaria de propor uma definição ligeiramente diferente, curta e precisa do que Dependency Injection é, com foco no objetivo principal, e não sobre os meios técnicos (seguindo ao longo de aqui ):

Dependency Injection é o processo de criação do estático, sem estado gráfico de objectos de serviço, em que cada serviço está parametrizado pelo seu dependências.

Os objetos que criamos em nossas aplicações (independentemente se usarmos Java, C # ou outra linguagem orientada a objetos) geralmente caem em uma das duas categorias: sem estado, estáticos e “objetos de serviço” globais (módulos), e stateful, dinâmica e “objetos de dados” locais.

O gráfico módulo - o gráfico de objetos de serviço - normalmente é criado na inicialização do aplicativo. Isto pode ser feito usando um recipiente, tal como a mola, mas também pode ser feito manualmente, por passagem de parâmetros para construtores de objectos. Ambas as formas têm seus prós e contras, mas uma estrutura definitivamente não é necessário o uso de DI na sua aplicação.

Uma exigência é que os serviços devem ser parametrizado por suas dependências. O que isso significa exatamente depende da linguagem e abordagem em um determinado sistema. Normalmente, este assume a forma de parâmetros do construtor, mas usando setters também é uma opção. Isto também significa que as dependências de um serviço estão escondidos (ao chamar um método de serviço) dos usuários do serviço.

Quando usar? Eu diria sempre que a aplicação é grande o suficiente para que encapsular a lógica em módulos separados, com um gráfico de dependência entre os módulos dá um ganho em legibilidade e explorability do código.

Dependency Injection é um tipo de implementação do " Inversão de Controle " princípio sobre o qual é Frameworks baseados construção.

Frameworks como indicado em "Design Pattern" de GoF são classes que implementam a lógica do fluxo de controle principal elevando o desenvolvedor para fazer isso, desta forma Frameworks realizar a inversão do princípio de controle.

A maneira de implementar como uma técnica, e não como hierarquia de classes, este princípio IoC é apenas Dependency Injection.

DI consiste principalmente em delegado o mapeamento de instâncias classes e tipo de referência para que as instâncias, para uma "entidade" externa: um objeto, classe estática, componente, estrutura, etc ...

casos classes são o " dependências ", a ligação a externo do componente de chamada com a instância de classe através da referência é o " injeco ".

Obviamente você pode implementar esta técnica em muitas maneira como você quer do ponto OOP de vista, ver, por exemplo injeção de construtor , injeção setter , injeção de interface .

Delegar a terceiros para realizar a tarefa de jogo um ref para um objeto que ele é muito útil quando você quer separar completamente um componente que precisa de alguns serviços a partir da implementação mesmos serviços.

Desta forma, ao projetar componentes, você pode se concentrar exclusivamente em sua arquitetura e sua lógica específica, confiando em interfaces para colaborar com outros objetos sem se preocupar com qualquer tipo de mudanças de implementação de objetos / serviços utilizados, também, se o mesmo objeto você está usando será totalmente substituída (obviamente respeitando a interface).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top