O que é inversão de controle?

Inversão do controlo é o que se obtém quando o programa é chamado de volta, por exemplo, como um programa gui.

Por exemplo, num menu antigo, você pode ter:

print "enter your name"
read name
print "enter your address"
read address
etc...
store in database

Controlando assim o fluxo da interacção do utilizador.

Num programa GUI ou somesuch, em vez disso dizemos:

when the user types in field a, store it in NAME
when the user types in field b, store it in ADDRESS
when the user clicks the save button, call StoreInDatabase

Basicamente, qualquer coisa com um loop de eventos, callbacks ou execute gatilhos cai nesta categoria.

Se seguir estes dois passos simples, fez inversão de controlo:

1. separar o que-fazer parte de Quando-fazer parte.
2. Garantir que quando parte sabe como pouco quanto possível sobre que parte; e vice-versa.

--

A inversão parte da inversão do controlo (COI) é a coisa confusa; porque inversão é o termo relativo. A melhor maneira de entender o COI é esquecer essa palavra!

--

Exemplos

• Manipulação De Eventos. Responsáveis por eventos (parte "o que fazer") -- angariação de eventos (parte "quando fazer")
Interfaces. Cliente do componente (quando-por-fazer parte) -- implementação da Interface do componente (o que-por-fazer Parte) XUnit fixure. Setup and TearDown ( what-to-do part) -- xUnit frameworks calls to Setup at the beginning and TearDown at the end (when-to-do part)
• Modelo método padrão de desenho. modelo do método quando-por - fazer parte -- implementação de subclasse primitiva do que-fazer parte
• Método do contentor DLL em COM. DllMain, DllCanUnload, etc (what-to-do part) -- COM/os (when-to-do part)

Sem o IoC : você tem um computadorPortátil e acidentalmente quebra o ecrã. E raios, você acha que o mesmo modelo de tela de laptop não está em nenhum lugar no mercado. Então estás preso.

Com o IoC : você tem um computador desktop e quebra acidentalmente o ecrã. Você acha que você pode apenas pegar quase qualquer monitor desktop do mercado, e ele funciona bem com o seu desktop.

O seu o desktop implementa com sucesso o COI neste caso. Ele aceita um tipo variado de monitores, enquanto o laptop não, ele precisa de uma tela específica para ser corrigido.

Inversão do controle, (ou COI), é sobre obter liberdade (você se casa, você perdeu a liberdade e você está sendo controlado. Divorciaste-te, acabaste de implementar a inversão do controlo. Era o que chamávamos de "dissociado". Um bom sistema informático desencoraja uma relação muito próxima.) mais flexibilidade (a cozinha do seu escritório só serve água da torneira limpa, essa é a sua única escolha quando quer beber. O seu chefe implementou a inversão do controlo através da criação de um nova máquina de café. Agora você tem a flexibilidade de escolher água da torneira ou café.( o seu parceiro tem um emprego, você não tem um emprego, você depende financeiramente de seu parceiro, então você é controlado. Você encontra um emprego, você implementou inversão de controle. Um bom sistema informático encoraja a dependência.)

Quando se usa um computador de secretária, tem-se escravizado (ou, digamos, controlado). Tens de te sentar à frente de um ecrã e olhar para ele. Usar o teclado para escrever e usando o mouse para navegar. E um software mal escrito pode escravizar-te ainda mais. Se você substituir seu desktop com um laptop, então você inverteu um pouco o controle. Você pode facilmente pegá-lo e mover-se ao redor. Então agora você pode controlar onde você está com seu computador, em vez de seu computador controlá-lo.

Ao implementar a inversão do controlo, um consumidor de software/objecto obtém mais controlos/opções sobre o software/objectos, em vez de ser controlado ou ter menos opções.

Com as ideias acima em mente. Ainda perdemos uma parte importante do COI. No cenário do COI, o consumidor de software/objeto é um quadro sofisticado. Isso significa que o código que criou não é chamado por si mesmo. Agora vamos explicar por que esta maneira funciona melhor para uma aplicação web.

As aplicações web modernas com uma arquitectura MVC dependem da estrutura para fazer URL Roteamento e colocar controladores no lugar para o framework chamar.

A injecção de dependência e a inversão do controlo estão relacionadas. A injecção de dependência está ao nível de micro e a inversão do controlo está ao nível de macro. Você tem que comer cada mordida (implementar DI), a fim de terminar uma refeição (implementar coi).

Antes de utilizar a inversão do controlo, deve estar bem ciente do facto de que tem os seus prós e contras e deve saber porque a utiliza se o fizer.

Prós:

• o seu código é dissociado para que possa facilmente trocar implementações de uma interface com implementações alternativas
• é um forte motivador para codificar contra interfaces em vez de implementações
É muito fácil escrever testes de unidade para o seu código, porque não depende de mais nada. do que os objetos que aceita em seu construtor/setters e você pode facilmente inicializá-los com os objetos certos em isolamento.

Conts:

• o COI não só inverte o fluxo de controlo no seu programa, como também o tolda consideravelmente. Isso significa que você não pode mais simplesmente ler seu código e saltar de um lugar para outro, porque as conexões que normalmente estariam em seu código não estão mais no código. Em vez disso, está em arquivos de configuração XML ou anotações e no código do seu contentor de Coi que interpreta estes metadados.
• surge uma nova classe de bugs onde você obtém sua configuração XML ou suas anotações erradas e você pode passar muito tempo descobrindo por que o seu contêiner de Coi injeta uma referência nula em um de seus objetos sob certas condições.

1. Artigo Da Wikipédia. Para mim, a inversão do controlo está a transformar o teu código sequencialmente escrito e a transformá-lo numa estrutura de delegação. Em vez de seu programa controlar tudo explicitamente, seu programa configura uma classe ou biblioteca com certas funções a serem chamadas quando certas coisas acontecem.

2. Resolve a duplicação de código. Por exemplo, nos velhos tempos você escreveria manualmente o seu próprio loop de eventos, pesquisando as bibliotecas do sistema para novos eventos. Hoje em dia, a maioria das APIs modernas você simplesmente diz às bibliotecas do sistema em que eventos você está interessado, e ele vai deixar você saber quando eles acontecem.

3. Inversão de controle é uma maneira prática de reduzir a duplicação de código, e se você se encontrar copiando um método inteiro e apenas mudando um pequeno pedaço do código, você pode considerar abordá-lo com inversão de controle. A inversão do controle é facilitada em muitas línguas através do conceito de delegados, interfaces, ou mesmo raw ponteiros de função.

   Não é apropriado usar em todos os casos, porque o fluxo de um programa pode ser mais difícil de seguir quando escrito desta forma. É uma maneira útil de projetar métodos ao escrever uma biblioteca que será reutilizada, mas deve ser usada com moderação no núcleo de seu próprio programa, a menos que ele realmente resolva um problema de duplicação de código.

Como neste exemplo com o TextEditor: se você tem apenas um SpellChecker talvez não seja realmente necessário usar o COI ? A não ser que precises de fazer testes de unidade ou algo assim ...

Sem IoC: você pede "maçã", e você é sempre servido maçã quando você pede mais.

Com o COI : podes pedir "fruta". Você pode obter frutas diferentes cada vez que você é servido. por exemplo, maçã, laranja ou melão de água.

O COI / DI para mim está a empurrar dependências para os objectos chamadores. Super simples.

1. Inversão de controle é um padrão usado para dissociar componentes e camadas no sistema. O padrão é implementado através da injeção de dependências em um componente quando ele é construído. Estas dependências são geralmente fornecidas como interfaces para uma maior dissociação e para apoiar a testabilidade. Contentores IoC / DI, como o Castelo Windsor, Unity são ferramentas (bibliotecas) que podem ser usadas para fornecer coi. Essas ferramentas fornecem recursos estendidos acima e além da dependência simples gestão, incluindo vida, AOP / intercepção, política, etc.

2. A. alivia um componente de ser responsável por gerenciar suas dependências.
   B. Provides the ability to swap dependency implementations in different environments.
   C. permite que um componente seja testado através de troça de dependências.
   D. fornece um mecanismo para compartilhar recursos ao longo de uma aplicação.

3. A. crítica ao fazer o desenvolvimento orientado por testes. Sem coi pode ser difícil de testar, porque os componentes em ensaio estão altamente acoplados ao resto do sistema.
   B. crítica ao desenvolver sistemas modulares. Um sistema modular é um sistema cujos componentes podem ser substituídos sem necessidade de recompilação.
   C. crítica se há muitas preocupações transversais que precisam ser abordadas, principalmente em uma aplicação empresarial.

Vou escrever a minha simples compreensão destes dois termos.:

For quick understanding just read examples*

Injecção de Dependência (DI):
Injeção de dependência geralmente significa passar um objeto sobre o qual o método depende, como um parâmetro para um método, ao invés de ter o método criar o objeto dependente. Na prática, o que significa é que o método não depende directamente de uma determinada implementação; qualquer implementação que satisfaça os requisitos pode ser aprovada como uma parametro.

com estes objectos, diga às dependências de thier. E a primavera torna-o disponível. Isto conduz a um desenvolvimento de aplicações pouco interligadas.

Quick Example:EMPLOYEE OBJECT WHEN CREATED,
              IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT
   (if address is defines as dependency by Employee object)

Reservatório de inversão do comando(coi) :
Esta é uma característica comum dos enquadramentos, O IOC gere objectos java
– da instanciação à destruição através do seu BeanFactory.
- componentes Java instanciados pelo recipiente do COI são chamados de feijões, e o recipiente do COI gerencia o escopo de um bean, eventos de ciclo de vida, e quaisquer recursos da AOP para os quais ele foi configurado e codificado.

QUICK EXAMPLE:Inversion of Control is about getting freedom, more flexibility, and less dependency. When you are using a desktop computer, you are slaved (or say, controlled). You have to sit before a screen and look at it. Using keyboard to type and using mouse to navigate. And a bad written software can slave you even more. If you replaced your desktop with a laptop, then you somewhat inverted control. You can easily take it and move around. So now you can control where you are with your computer, instead of computer controlling it.

Ao implementar a inversão do controlo, um consumidor de software/objecto obtém mais controlos/opções sobre o software/objectos, em vez de ser controlado ou ter menos opções.

Inversão do controlo como orientação de projecto serve os seguintes objectivos::

Explicação pormenorizada

Inversão De Controle (coi) significa criar instâncias de dependências em primeira e última instância de uma classe (opcionalmente injectando-as através do construtor), em vez de criar uma instância da classe em primeiro lugar e, em seguida, a instância de classe criando instâncias de dependências. Assim, a inversão do controle inverte o fluxo do controle do programa. em vez de o controlo de chamadas o fluxo de control (ao criar dependências), o chamador controla o fluxo de controlo do programa.

Por exemplo, a tarefa#1 é criar um objecto. Sem o conceito do COI, a tarefa número 1 deve ser feita pelo programador.Mas com o conceito do COI, a tarefa # 1 seria feita por container.

Encontrei um bom exemplo aqui .

Concordo com NilObject , mas gostaria de acrescentar a isto:

Se te encontrares a copiar um método inteiro e a mudar apenas um pequeno pedaço do Código, podes considerar enfrentá-lo com inversão do controlo

Se você se encontra copiando e colando o código em torno, Você está quase sempre fazendo algo errado. Codificado como princípio do projecto uma vez e apenas uma vez .

Parece que a coisa mais confusa sobre "IoC" o acrónimo e o nome para o qual está é que é demasiado glamouroso de um nome - quase um nome de ruído.

E isto é exatamente o que a mola (outro recipiente do COI, por exemplo: Guice) faz. Em vez de deixar a aplicação criar o que precisa usando a nova palavra-chave (tomando copo de plástico), recipiente de mola IoC todo o tempo oferecer para aplicar o a mesma instância (singleton) do objecto necessário(copo de água).

Exemplo:-

public class MeetingMember {

    private GlassOfWater glassOfWater;

    ...

    public void setGlassOfWater(GlassOfWater glassOfWater){
        this.glassOfWater = glassOfWater;
    }
    //your glassOfWater object initialized and ready to use...
    //spring IoC  called setGlassOfWater method itself in order to
    //offer to meetingMember glassOfWater instance

}

Útil ligações:-

• http://adfjsf.blogspot.in/2008/05/inversion-of-control.html
• http://martinfowler.com/articles/injection.html
• http://www.shawn-barrett.com/blog/post/Tip-of-the-day-e28093-Inversion-Of-Control.aspx

O COI tem a ver com inverter a relação entre o seu código e o código de terceiros (biblioteca / estrutura):

• em desenvolvimento S / w normal, você escreve o principal() method and call "library" methods. Tu. estão no controlo:)
• in IoC the" framework " controls principal() e chama os teus métodos. O enquadramento está no controlo: (

DI (injeção de dependência) é sobre como o controlo flui em aplicacao. A aplicação de desktop tradicional tinha fluxo de controle de sua aplicação (método main ()) para outras chamadas de método de biblioteca, mas com o fluxo de controle DI está invertida que é framework cuida de iniciar o seu aplicativo, inicializando-o e invocando seus métodos sempre que necessário.

Encontrei um exemplo muito claro aqui {[7] } que explica como o 'controlo está invertido'.

Código clássico (sem injeção de Dependência)

Aqui está como um código que não usa DI vai funcionar aproximadamente:

• A aplicação necessita de Foo( por exemplo, um controlador), por isso:
• A aplicação cria Foo
• A aplicação chama Foo
  • o Foo precisa de uma barra (por exemplo, um serviço), por isso:
  • Foo cria Bar
  O Foo chama o Bar
  As necessidades do Bar Bim (um serviço, um repositório, ...), então:
• Bar cria Bim
O Bar faz alguma coisa.

Usar a injecção de dependência

Aqui está como um código usando DI vai funcionar aproximadamente:

• A aplicação precisa de Foo, que precisa de barra, que precisa de Bim, por isso:
• A aplicação cria o Bim
• A aplicação cria uma barra e dá-lhe Bim
• A aplicação cria Foo e dá-lhe Bar
• chamadas de aplicações X
  O Foo chama o Bar
  O Bar faz alguma coisa.

o controle das dependências é invertido de um ser chamado para o chamado.

Que problemas resolve?

A injecção de Dependência facilita a troca com a implementação diferente das classes injectadas. Enquanto o teste de unidade você pode injectar uma implementação fictícia, o que torna o teste muito mais fácil.

Ex: Suponha que a sua aplicação armazena o ficheiro enviado pelo utilizador no Google Drive, com DI o seu código de controlador pode parecer o seguinte:

class SomeController
{
    private $storage;

    function __construct(StorageServiceInterface $storage)
    {
        $this->storage = $storage;
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

class GoogleDriveService implements StorageServiceInterface
{
    public function authenticate($user) {}
    public function putFile($file) {}
    public function getFile($file) {}
}

Em vez disso, se tivesse a classe do controlador para construir o objecto de armazenamento com a palavra-chave new como esta:

class SomeController
{
    private $storage;

    function __construct()
    {
        $this->storage = new GoogleDriveService();
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

Quando quiser mudar com a implementação do Dropbox, terá de substituir todas as linhas onde o objecto do GoogleDriveService é construído e usar o DropboxService. Além disso, ao testar a classe SomeController o construtor sempre espera que a classe GoogleDriveService e os métodos reais desta classe são acionados.

Quando e quando? Na minha opinião, você usa DI quando você acha que há (ou pode haver) implementações alternativas de uma classe.

A inversão do controle é quando você vai ao Supermercado e sua esposa lhe dá a lista de produtos para comprar.

Em termos de programação, ela passou uma função de callback {[[0]} para a função que está a executar doShopping();

Permite ao Utilizador da função definir algumas partes dela tornando-a mais flexível.

Uma explicação escrita muito simples pode ser encontrada aqui

Http://binstock.blogspot.in/2008/01/excellent-explanation-of-dependency.html

" qualquer aplicação não trivial é constituída por duas ou mais classes que colaborem uns com os outros para realizar alguma lógica de negócios. Tradicionalmente, cada objeto é responsável por obter o seu próprio referências aos objetos com os quais colabora (suas dependências). Ao aplicar DI, os objectos são dadas as suas dependências na criação tempo por alguma entidade externa que coordena cada objecto no sistema. Em outras palavras, dependências são injetadas em objetos."

COI em termos fáceis: é o uso da Interface como uma forma de algo específico (tal campo ou parâmetro) como um wildcard que pode ser usado por algumas classes. Permite a reutilização do Código.

A) a maioria dos programadores não sabe como usá-lo. Por exemplo, posso criar uma classe chamada Cliente e I pode criar automaticamente (usando as ferramentas do IDE) uma interface chamada ICustomer. Então, não é raro encontrar uma pasta cheia de classes e interfaces, não importa se as interfaces serão reutilizadas ou não. Chama-se inchado. Algumas pessoas poderiam argumentar que"pode ser no futuro que poderíamos usá-lo". :-|

B. 1) Se eu adicionar {[[0]} ao Serviço AnimalService então também funciona com gatos e não é válido de todo.

B. 2) Posso adicionar uma condição em {[[0] } onde avalia qual a classe utilizada. Mas vai quebrar completamente o COI.

B. 3) Posso criar uma nova classe de serviço chamada DogService apenas para a nova funcionalidade. Mas, irá aumentar a manutenção do Código porque teremos duas classes de serviço (com funcionalidade) para cão e é mau.

A inversão do controlo é um princípio genérico, enquanto a injeção de Dependência realiza este princípio como um padrão de desenho para a construção de grafos de objectos (ou seja, a configuração controla como os objectos estão a referenciar-se uns aos outros, em vez de o próprio objecto controlar como obter a referência a outro objecto).

Para os interessados em mais profundidade sobre Inversão de Controle de um papel que tem sido publicado o esboço de um quadro mais completo de Inversão de Controle, como um padrão de projeto (OfficeFloor: usando o office padrões para melhorar o design de software http://doi.acm.org/10.1145/2739011.2739013 com uma cópia gratuita disponível para download a partir de http://www.officefloor.net/mission.html)

O que é identificado é o seguinte: relação:

Inversão do controlo (para métodos) = Injecção de Dependência (estado) + Injecção de continuação + Injecção de rosca

Gosto desta explicação: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

Ele começa simples e mostra exemplos de código também.

Não é suficiente que X saiba que usa algo que tem o comportamento, os métodos, propriedades etc, de Y sem saber quem realmente implementa o comportamento?

Extraindo uma definição abstracta do comportamento usado por X em Y, ilustrada como I abaixo, e deixando o consumidor X usar uma instância disso em vez de Y, pode continuar a fazer o que faz sem ter de saber as especificidades sobre Y.

Na ilustração acima y implementa I e X usa uma instância de I. enquanto é bem possível que X ainda usa Y o que é interessante é que X não usa saber. Só sabe que usa algo que implementa I.

Leia o artigo para mais informações e descrição das prestações, tais como:

• X já não depende de Y
• mais flexível, a implementação pode ser decidida em tempo de execução
• isolamento da unidade de código, testes mais fáceis

...

A inversão do controlo (COI) foi construída com base num princípio muito simples chamado Princípio de Hollywood . E diz que ...

Não nos ligues, nós ligamos-te.

No nosso mundo de programação, Hollywood representa um quadro genérico (pode ser escrito por si ou por outra pessoa), você representa o código de utilizador que escreveu e a tarefa representa a coisa que você escreveu quero cumprir o seu código. Agora, nunca vais activar a tua tarefa sozinho, não no COI! Em vez disso, desenhastes tudo de tal forma que o vosso quadro irá despoletar a vossa tarefa para vós. Assim você construiu uma estrutura reutilizável que pode fazer de alguém um herói ou outro um vilão. Mas esse quadro está sempre no comando, ele sabe quando escolher alguém e que alguém só sabe o que ele quer ser.

E depois deixa alguns ganchos na sua estrutura onde pode colocar mais códigos para gerar menu personalizado, páginas, cookies ou registar alguns eventos do Utilizador, etc. Em cada pedido de navegador, o seu framework irá executar e executar os seus códigos personalizados se ligado, em seguida, servi-lo de volta ao navegador.

Laravel e e EJB são exemplos desse tipo de quadro.

Referência:

Https://martinfowler.com/bliki/InversionOfControl.html

Https://en.wikipedia.org/wiki/Inversion_of_control

Inversão de controle é sobre a transferência de controle da biblioteca para o cliente. Faz mais sentido quando falamos de um cliente que injeta (passa) um valor de função (expressão lambda) em uma função de ordem superior (função biblioteca) que controla (muda) o comportamento da função biblioteca. Um cliente ou framework que injeta dependências de bibliotecas (que transportam comportamento) em bibliotecas também pode ser considerado IoC

1. Então número 1 acima de . O que é a inversão do controlo?

2. A manutenção é a primeira coisa que resolve para mim. Garante que estou usando interfaces para que duas classes não sejam íntimas uma com a outra.

public class MessagePublisher<RECORD,MESSAGE>
{
    public MessagePublisher(IMapper<RECORD,MESSAGE> mapper,IRemoteEndpoint endPointToSendTo)
    {
      //setup
    }
}

Escrevi-o uma vez, mas agora posso injectar muitos tipos neste conjunto de código se publicar diferentes tipos de mensagens. Eu também posso escrever mappers que tomam um registro do mesmo tipo e mapa para mensagens diferentes. Usar DI com genéricos deu-me a capacidade de escrever muito pouco código para realizar muitas tarefas.

3 . Torna-se mais apropriado no minuto em que você tem um projeto de tamanho médio de um pouco mais complexidade. Eu diria que se torna apropriado assim que começares a sentir dor.

Criar um objecto dentro da classe é chamado de acoplamento apertado, a mola remove esta dependência seguindo um padrão de desenho(DI/IOC). Em que o objeto da classe em passou no construtor ao invés de criar na classe. Mais sobre nós damos a variável de referência de super classe no construtor para definir uma estrutura mais geral.

O que é?

É uma prática em que você deixa o comportamento real vir de fora do limite (classe na programação orientada a objetos). Limite a entidade só conhece a abstração (por exemplo, interface, classe abstrata, delega em Programação Orientada a objetos) dela.

Que problemas resolve?

Quando e quando?

É apropriado a maior parte do tempo, a menos que você tenha uma situação em que você só quer o código monolítico (por exemplo, muito programa simples)

Usando o COI, não está a criar novos objectos. O seu Contentor de Coi fará isso e gerirá a vida deles.

É apropriado quando você tem uma funcionalidade que pode mudar no futuro ou que pode ser diferente dependendo do ambiente ou configuração utilizada.