O que é inversão de controle?

votos
1k

Inversão de Controle (ou IoC) pode ser um pouco confuso quando se encontraram pela primeira vez.

  1. O que é isso?
  2. Quais os problemas que ele resolve?
  3. Quando é apropriado e quando não?
Publicado 06/08/2008 em 04:35
fonte usuário
Em outras línguas...                            


32 respostas

votos
1k

A inversão de controle (COI) e Dependency Injection padrões (DI) são todos sobre como remover as dependências do seu código.

Por exemplo, digamos que seu aplicativo tem um componente de editor de texto e você deseja fornecer a verificação ortográfica. Seu código padrão seria algo parecido com isto:

public class TextEditor {

    private SpellChecker checker;

    public TextEditor() {
        this.checker = new SpellChecker();
    }
}

O que nós fizemos aqui cria uma dependência entre o TextEditoreo SpellChecker. Em um cenário de IoC que, ao invés, fazer algo como isto:

public class TextEditor {

    private IocSpellChecker checker;

    public TextEditor(IocSpellChecker checker) {
        this.checker = checker;
    }
}

No primeiro exemplo de código que são instanciar SpellChecker( this.checker = new SpellChecker();), o que significa que a TextEditorclasse depende directamente da SpellCheckerclasse.

No segundo exemplo de código estamos criando uma abstração por ter a SpellCheckerclasse de dependência na TextEditorassinatura de construtor (não inicializar dependência em sala de aula). Isso nos permite chamar a dependência em seguida, passá-lo para a classe TextEditor assim:

SpellChecker sc = new SpellChecker; // dependency
TextEditor textEditor = new TextEditor(sc);

Agora o cliente criar a TextEditorclasse tem o controle sobre quais SpellCheckerimplementação de usar, porque nós estamos injetando a dependência à TextEditorassinatura.

Este é apenas um exemplo simples, há uma boa série de artigos por Simone Busoli que explica em maior detalhe.

Respondeu 06/08/2008 em 08:22
fonte usuário

votos
485

Inversão de Controle é o que você começa quando seus retornos de chamada do programa, por exemplo, como um programa de gui.

Por exemplo, em um menu velha escola, você pode ter:

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

controlando desse modo o fluxo de interacção do utilizador.

Em um programa de GUI ou algo assim, em vez disso, dizem

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

Então agora o controle é invertido ... em vez da entrada do usuário aceitar computador em uma ordem fixa, o usuário controla a ordem em que os dados são inseridos, e quando os dados são salvos no banco de dados.

Basicamente, qualquer coisa com um ciclo de eventos, retornos de chamada ou gatilhos executar cai nesta categoria.

Respondeu 06/08/2008 em 06:42
fonte usuário

votos
356

O que é inversão de controle?

Se você seguir estas simples dois passos, você tem feito inversão de controle:

  1. Separe o que -para-fazer parte de quando -a-separe.
  2. Certifique-se que quando parte sabe como pouco quanto possível sobre o que parte; e vice versa.

Existem várias técnicas possíveis para cada uma dessas etapas com base na tecnologia / linguagem que você está usando para sua implementação.

-

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

-

Exemplos

  • Manipulação de eventos. Manipuladores de Eventos (o que-fazer parte) - Eventos Raising (quando-a-fazer parte)
  • Interfaces. cliente componente (quando-a-fazer parte) - Componente de implementação Interface (o que-fazer parte)
  • fixure xUnit. Instalação e subdivisão (que-a-fazer parte) - estruturas xUnit chama a configuração no início e TearDown no final (quando-a-fazer parte)
  • Modelo padrão de projeto método. método de modelo quando-a-fazer parte - implementação subclasse primitiva que-a-fazer parte
  • métodos recipiente DLL no COM. DllMain, DllCanUnload, etc (que-a-fazer parte) - COM / OS (quando-to-do parte)
Respondeu 22/07/2010 em 18:34
fonte usuário

votos
81

Inversão dos Controlos é de cerca de separação preocupações.

Sem IoC : Você tem um laptop computador e você acidentalmente quebrar a tela. E danado, você encontra a mesma tela modelo de laptop é em nenhum lugar do mercado. Então você está preso.

Com IoC : Você tem uma área de trabalho do computador e você acidentalmente quebrar a tela. Você achar que você pode simplesmente pegar praticamente qualquer monitor de desktop do mercado, e ele funciona bem com o seu desktop.

Sua área de trabalho implementa com sucesso IoC neste caso. Ele aceita um tipo de variedade de monitores, enquanto o laptop não faz, ele precisa de uma tela específica para ficar fixo.

Respondeu 25/09/2013 em 15:24
fonte usuário

votos
77

Inversão de Controle, (ou IoC), é de cerca de obter a liberdade (Você se casar, você perdeu a liberdade e você está sendo controlado. Você divorciada, você tem apenas implementado inversão de controle. Isso é o que chamamos, "dissociado". Boa sistema de computador desencoraja alguma relação muito próxima.) mais flexibilidade (a cozinha em seu escritório serve apenas água limpa da torneira, que é sua única opção quando você quer beber. seu chefe implementado inversão de controle através da criação de uma nova máquina de café. Agora você começa a flexibilidade de escolher qualquer água da torneira ou café.) e menor dependência (Seu parceiro tem um emprego, você não tem um emprego, você depender financeiramente de seu parceiro, para que sejam controladas. Você encontrar um emprego, você implementou inversão de controle. Boa sistema de computador incentiva in-dependência.)

Quando você usa um computador desktop, você escravo (ou dizer, controlado). Você tem que sentar-se diante de uma tela e olhar para ele. Usando o teclado para digitar e usar o mouse para navegar. E um software mal escrito pode trabalhar como escravo-lo ainda mais. Se você substituir o seu desktop com um laptop, então você um pouco invertida controle. Você pode facilmente levá-lo e se movimentar. Então, agora você pode controlar onde você está com o seu computador, em vez de seu computador controlá-la.

Com a implementação de inversão de controle, um consumidor software / object obter mais controles / opções sobre o software / objetos, em vez de ser controlado ou ter menos opções.

Com as idéias acima em mente. Nós ainda falta uma parte fundamental do COI. No cenário de IoC, o consumidor software / object é uma estrutura sofisticada. Isso significa que o código que você criou não é chamado por si mesmo. Agora vamos explicar o porquê desta forma funciona melhor para uma aplicação web.

Suponha que seu código é um grupo de trabalhadores. Eles precisam construir um carro. Esses trabalhadores precisam de um lugar e ferramentas (uma estrutura de software) para construir o carro. A tradicional estrutura de software será como uma garagem com muitas ferramentas. Assim, os trabalhadores precisam fazer um plano de si mesmos e usar as ferramentas para construir o carro. Construir um carro não é um negócio fácil, será muito difícil para os trabalhadores para planejar e cooperar adequadamente. A modernaestrutura de software será como uma fábrica de automóveis moderno, com todas as facilidades e gestores no local. Os trabalhadores não têm que fazer qualquer plano, os gestores (parte do quadro, eles são as pessoas mais inteligentes e fez o plano mais sofisticado) vai ajudar a coordenar de modo que os trabalhadores saber quando fazer o seu trabalho (framework chama o código). Os trabalhadores só precisa ser flexível o suficiente para usar todas as ferramentas os gestores dão a eles (usando Dependency Injection).

Embora os trabalhadores dão o controle do gerenciamento do projeto no nível superior para os gestores (o quadro). Mas é bom ter alguns profissionais ajudar. Este é o conceito de IoC realmente vêm.

aplicações Web modernas, com uma arquitetura MVC depende do quadro para fazer URL roteamento e colocar controladores no lugar para o quadro chamar.

Dependency Injection e inversão de controle estão relacionados. Dependency Injection está no micro nível e inversão de controle está no macro nível. Você tem que comer cada mordida (implementar DI), a fim de terminar uma refeição (implementar COI).

Respondeu 04/03/2013 em 20:33
fonte usuário

votos
72

Antes de usar inversão de controle você deve estar bem ciente do fato de que ele tem seus prós e contras e você deve saber por que você usá-lo se você fizer isso.

prós:

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

contras:

  • IoC não só inverte o fluxo de controle em seu programa, ele também obscurece-se consideravelmente. Isso significa que você já não pode apenas ler o seu código e saltar de um lugar para outro, porque as conexões que normalmente seriam no seu código não está no código mais. Em vez disso, está em arquivos de configuração XML ou anotações e no código do seu contêiner IoC que interpreta esses metadados.
  • Surge uma nova classe de erros onde você obtém sua configuração XML ou suas anotações errado e você pode gastar um monte de tempo a descobrir por que seu contêiner IoC injeta uma referência nula em um dos seus objetos sob certas condições.

Pessoalmente eu ver os pontos fortes do COI e eu realmente gosto deles, mas eu tendem a evitar IoC, sempre que possível, pois transforma o seu software em uma coleção de classes que já não constituem um programa de "real", mas apenas algo que precisa ser colocado em conjunto por configuração XML ou metadados de anotação e cairiam (e quedas) distante sem ele.

Respondeu 12/02/2010 em 15:31
fonte usuário

votos
55
  1. Wikipedia artigo . Para mim, inversão de controle é transformar o seu código escrito sequencialmente e transformá-lo em uma estrutura de delegação. Em vez de seu programa de controlar explicitamente tudo, o seu programa configura uma classe ou biblioteca com certas funções a ser chamado quando certas coisas acontecem.

  2. Ele resolve a duplicação de código. Por exemplo, nos velhos tempos, você manualmente escrever o seu próprio ciclo de eventos, polling as bibliotecas do sistema para novos eventos. Hoje em dia, a maioria das APIs modernas que simplesmente dizer as bibliotecas do sistema que eventos que você está interessado, e ele vai deixar você saber quando eles acontecem.

  3. Inversão de controle é uma maneira prática para reduzir a duplicação de código e se você se encontra a cópia de um método inteiro e só mudar um pequeno pedaço de código, você pode considerar a enfrentá-lo com inversão de controle. Inversão de controle é facilitado em muitas línguas através do conceito de delegados, interfaces, ou ponteiros de função, mesmo crus.

    Não é apropriado para 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 para projetar métodos ao escrever uma biblioteca que será reutilizada, mas deve ser usado com moderação no núcleo do seu próprio programa, a menos que realmente resolve um problema duplicação de código.

Respondeu 06/08/2008 em 05:33
fonte usuário

votos
38

Mas eu acho que você tem que ter muito cuidado com ele. Se você overuse este padrão, você vai fazer o projeto muito complicado e código ainda mais complicado.

Como neste exemplo com TextEditor: se você tiver apenas um SpellChecker talvez ele não é realmente necessário usar IoC? A menos que você precisa escrever testes de unidade ou algo assim ...

Enfim: ser razoável. Design padrão são boas práticas , mas não Bíblia deve ser pregado. Não colocá-lo em todos os lugares.

Respondeu 06/08/2008 em 23:08
fonte usuário

votos
34

Suponha que você é um objeto. E você vai a um restaurante:

Sem IoC : você pedir "maçã", e você está sempre servido maçã quando você perguntar mais.

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

Então, obviamente, IoC é preferida quando você gosta das variedades.

Respondeu 25/09/2013 em 15:00
fonte usuário

votos
34

IOC / DI para mim está empurrando para fora dependências para os objetos de chamada. Super simples.

A resposta não-techy é ser capaz de trocar um motor em um carro logo antes de ligá-lo. Se tudo conecta-se à direita (a interface), você é bom.

Respondeu 19/09/2008 em 03:54
fonte usuário

votos
23
  1. Inversão de controlo é um teste padrão usado para separar os componentes e camadas do sistema. O padrão é implementado por meio de injecção de dependências num componente quando ele for construído. Estas dependências são normalmente fornecidos como interfaces para uma maior dissociação e apoiar a capacidade de teste. recipientes IOC / DI tais como castelo de Windsor, Unidade são ferramentas (bibliotecas) que podem ser utilizados para proporcionar CIO. Essas ferramentas fornecem recursos estendidos acima e além de gerenciamento de dependência simples, incluindo vida, AOP / Intercepção, política, etc.

  2. uma. Alivia um componente de ser responsável pela gestão de suas dependências.
    b. Fornece a capacidade de trocar as implementações de dependência em diferentes ambientes.
    c. Permite que um componente ser testado através zombando de dependências.
    d. Fornece um mecanismo de compartilhamento de recursos em toda a aplicação.

  3. uma. Crítica ao fazer o desenvolvimento orientado a testes. Sem IoC pode ser difícil para testar, porque os componentes sob teste sã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 a necessidade de recompilação.
    c. Critical se há muitas preocupações transversais que precisam abordados, partilarly em um aplicativo corporativo.

Respondeu 19/09/2008 em 03:27
fonte usuário

votos
17

Vou escrever a minha simples compreensão deste dois termos:

For quick understanding just read examples*

Injecção de dependência (DI):
Dependência injecção geralmente significa a passagem de um objecto no qual método depende, como um parâmetro para um método, em vez de ter a forma de criar o objecto dependente .
O que isso significa na prática é que o método não depende diretamente de uma implementação particular; qualquer implementação que atenda aos requisitos pode ser passado como um parâmetro.

Com este objetos contar vários daqueles dependências. E a primavera torna disponível.
Isto leva a acoplado vagamente desenvolvimento de aplicações.

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

Inversão de controle (COI) Recipiente:
Esta é uma característica comum de estruturas, COI gere objectos java
- de instanciação a destruição através da sua BeanFactory.
-java componentes que são instanciado pelo contêiner IoC são chamados de feijão, e o contêiner IoC administra âmbito de um bean, eventos de ciclo de vida, e quaisquer características AOP para o qual ele foi configurado e codificadas.

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.

Com a implementação de inversão de controle, um consumidor software / object obter mais controles / opções sobre o software / objetos, em vez de ser controlado ou ter menos opções.

Inversão de controlo como uma directriz desenho possui os seguintes objectivos:

Há uma dissociação entre a execução de uma determinada tarefa de implementação.
Cada módulo pode se concentrar no que ele é projetado para.
Módulos não fazer suposições sobre o que outros sistemas de fazer, mas confiar em seus contratos.
Substituição de módulos tem nenhum efeito colateral em outros módulos
I vai manter as coisas abstrato Aqui, você pode visitar seguintes links para detalhes compreensão do tema.
Uma boa leitura com o exemplo

Explicação detalhada

Respondeu 10/11/2014 em 08:43
fonte usuário

votos
15

Por exemplo, a tarefa # 1 é criar objeto. Sem conceito COI, tarefa # 1 é suposto ser feito por Programmer.But Com conceito COI, tarefa # 1 seria feito por contêiner.

Em suma Controlo fica invertida do programador para recipiente. Então, ele é chamado como inversão de controle.

Eu encontrei um bom exemplo aqui .

Respondeu 27/01/2010 em 13:15
fonte usuário

votos
14

Respondendo apenas a primeira parte. O que é isso?

Inversão de controle (COI) meios para criar exemplos de dependências primeiro e último exemplo de uma classe (opcionalmente injectando-os através do construtor), em vez de criar uma instância da classe primeiro e, em seguida, a instância de classe criar instâncias de dependências. Assim, a inversão do controlo inverte o fluxo de controlo do programa. Em vez do receptor controlar o fluxo de controlo (durante a criação de dependências), o chamador controla o fluxo de controlo do programa .

Respondeu 11/01/2016 em 00:49
fonte usuário

votos
14

Parece que a coisa mais confuso sobre "JCP" a sigla eo nome que ela representa é que é muito glamouroso de um nome - quase um nome de ruído.

Será que realmente precisamos de um nome pelo qual a descrever a diferença entre a programação procedural e orientado a eventos? OK, se precisarmos, mas precisamos escolher um novo "maior que a vida" nome que confunde mais do que resolve?

Respondeu 19/01/2011 em 04:50
fonte usuário

votos
13

Vamos dizer que nós fazemos alguma reunião em algum hotel.

Muitas pessoas, muitas garrafas de água, muitos copos de plástico.

Quando alguém quer beber, ela encher copo, bebida e jogar o copo no chão.

Depois hora ou algo que temos um chão coberto de copos de plástico e água.

Vamos controle invertido.

Na mesma reunião, no mesmo lugar, mas em vez de copos de plástico que temos um garçom com um copo de vidro (Singleton)

e todo o tempo que ela oferece para os hóspedes potável.

Quando alguém quer beber, ela começa a partir de garçom vidro, bebida e devolvê-lo de volta para garçom.

Deixando de lado a questão da última forma higiénica, de controle de processo de beber é muito mais eficaz e econômica.

E isso é exatamente o que o Primavera (outro contêiner IoC, por exemplo: Guice) faz. Em vez de deixar a aplicação criar o que precisa usando a nova palavra-chave (tendo copo de plástico), Primavera IoC recipiente todas oferta tempo para aplicação da mesma instância (singleton) do objeto necessário (copo de água).

Pense em você como o organizador da reunião. Você precisa o caminho a mensagem a administração do hotel que

membros reunidos precisará copo de água, mas não pedaço de bolo.

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

}

Links Úteis:-

Respondeu 26/09/2012 em 18:54
fonte usuário

votos
13

Concordo com NilObject , mas eu gostaria de acrescentar a esta:

se você se encontra a cópia de um método inteiro e só mudar um pequeno pedaço de código, você pode considerar a enfrentá-lo com inversão de controle

Se você está copiando e colando código ao redor, você está quase sempre fazendo algo errado. Codificados como princípio o projeto apenas uma única vez .

Respondeu 06/08/2008 em 06:20
fonte usuário

votos
10

IoC é sobre invertendo a relação entre seu código e código de terceiros (biblioteca / quadro):

  • Em s normais / w desenvolvimento, você escreve o main () método e chamar métodos "biblioteca". Você está no controle :)
  • Em IoC o "quadro" controla main () e chama seus métodos. O quadro está no controle :(

DI (Dependência de injecção) é sobre como o controlo flui na aplicação. aplicação desktop tradicional teve fluxo de controle do seu aplicativo (método main ()) para outras chamadas de método biblioteca, mas com fluxo de controle DI é invertido que é quadro cuida de iniciar seu aplicativo, inicializando-lo e invocando seus métodos sempre que necessário.

No final, você sempre ganhar :)

Respondeu 19/09/2014 em 19:25
fonte usuário

votos
7

Inversão de controle é um princípio genérico, enquanto Dependência Injecção realiza este princípio como um padrão de design para a construção de gráfico de objecto (ou seja, os controlos de configuração como os objectos são referenciam uns aos outros, em vez do objecto de um controlo próprio como para obter a referência a um outro objeto).

Olhando para inversão de controle como um padrão de design, precisamos olhar para o que estamos invertendo. Injecção dependência inverte controlo da construção de um gráfico de objectos. Se contada no termo do leigo, inversão de controle implica mudança no fluxo de controle do programa. Por exemplo. No aplicativo independente tradicional, temos método principal, de onde o controle é passado para outras bibliotecas de terceiros (no caso, usamos a função terceiro biblioteca festa), mas através de inversão de controle de controle é transferido do código da biblioteca de terceiros para o nosso código , como nós estamos tomando o serviço de biblioteca de terceiros. Mas há outros aspectos que precisam ser invertido dentro de um programa - por exemplo, a invocação de métodos e tópicos para executar o código.

Para aqueles interessados em mais profundidade sobre inversão de controle um papel foi publicada delineando um quadro mais completo de inversão de controle como um padrão de design (OfficeFloor: usando padrões de escritório para melhorar o design do software http://doi.acm.org/10.1145/ 2739011.2739013 com uma cópia gratuita disponível para download no http://www.officefloor.net/mission.html )

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

Inversão de controle (por métodos) = Injecção Continuação + Injecção rosca Dependência (estado) Injecção +

Respondeu 29/10/2015 em 04:27
fonte usuário

votos
7

falar de programação

COI em termos simples: É o uso da interface, como forma de algo específico (tal campo ou um parâmetro) como um curinga que pode ser usado por algumas classes. Ele permite que a reutilização do código.

Por exemplo, vamos dizer que temos duas classes: cão e gato . Ambos compartilha as mesmas qualidades / estados: idade, tamanho, peso. Então, ao invés de criar uma classe de serviço chamado DogService e CatService , posso criar uma única chamada AnimalService que permite o uso de cão e gato somente se eles usam a interface IAnimal .

No entanto, pragmaticamente falando, ele tem alguns para trás.

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

b) Ele tem algumas limitings. Por exemplo, vamos falar sobre o caso do cão e do gato e eu quero adicionar um novo serviço (funcionalidade) apenas para cães. Vamos dizer que eu quero para calcular o número de dias que eu preciso para treinar um cão ( trainDays()), para o gato é inútil, os gatos não podem ser treinados (estou brincando).

b.1) Se eu adicionar trainDays()ao Serviço AnimalService em seguida, ele também funciona com gatos e não é válida em tudo.

b.2) posso acrescentar uma condição na trainDays()qual ele avalia que classe é usada. Mas ele vai quebrar completamente o COI.

b.3) eu posso criar uma nova classe de serviço chamado DogService apenas para a nova funcionalidade. Mas, que irá aumentar a capacidade de manutenção do código porque teremos duas classes de serviço (com funcionalidade semelhante) para Dog e é ruim.

Respondeu 19/04/2015 em 12:07
fonte usuário

votos
7

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

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

diz

"Qualquer aplicativo não trivial é composta de duas ou mais classes que colaboram uns com os outros para executar alguma lógica de negócios. Tradicionalmente, cada objeto é responsável por obter as suas próprias referências aos objetos colabora com (suas dependências). Ao aplicar DI, o objetos são dadas as suas dependências em tempo de criação por alguma entidade externa que coordena cada objeto no sistema. em outras palavras, as dependências são injetadas em objetos ".

Respondeu 22/02/2013 em 15:13
fonte usuário

votos
6

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

É começar simples e mostra exemplos de código também.

digite descrição da imagem aqui

O consumidor, X, precisa a classe consumido, Y, para realizar algo. Isso é tudo bom e natural, mas que X realmente precisa saber que ele usa Y?

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

Ao extrair uma definição abstrata do comportamento usado por X, em Y, ilustrado como I abaixo, e deixando o consumidor X usar uma instância de que em vez de Y pode continuar a fazer o que faz sem ter que saber os detalhes sobre Y.

digite descrição da imagem aqui

Na ilustração acima Y implementa I e X usa uma instância de I. Embora seja bem possível que X ainda usa Y que é interessante é que X não sabe que. Ele só sabe que ele usa algo que implementa I.

Leia o artigo para obter mais informações e inscrição de benefícios, tais como:

  • X não é dependente de Y mais
  • Mais flexível, a implementação pode ser decidido em tempo de execução
  • Isolamento da unidade de código, testes mais fácil

...

Respondeu 16/02/2017 em 02:03
fonte usuário

votos
4

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 da função (expressão lambda) para uma maior função de ordem (função de biblioteca) que controla (mudanças) o comportamento da função de biblioteca. Um cliente ou estrutura que injeta dependências da biblioteca (que transportam comportamento) em bibliotecas também podem ser considerados IoC

Respondeu 24/12/2017 em 18:34
fonte usuário

votos
4

Eu encontrei um exemplo muito claro aqui que explica como o 'controle é invertida'.

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

Aqui é como um código não usando DI vai aproximadamente trabalhar:

  • Foo aplicação precisa (por exemplo, um controlador), da seguinte forma:
  • Aplicativo cria Foo
  • Aplicação chama Foo
    • Foo precisa Bar (por exemplo, um serviço), então:
    • Foo cria Bar
    • Foo chama Bar
      • Bar precisa Bim (um serviço, um repositório, ...), então:
      • Bar cria Bim
      • Bar faz algo

Usando injecção dependência

Aqui é como um código usando DI vai aproximadamente trabalhar:

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

O controlo das dependências é invertido a partir de um ser chamado para o chamado.

Quais os problemas que ele resolve?

Injeção de dependência torna mais fácil para trocar com o diferente implementação das classes injetados. Enquanto o teste de unidade você pode injetar uma implementação fictício, o que torna a testar muito mais fácil.

Ex: Suponha que seu aplicativo armazena o arquivo carregado usuário no Google Drive, com DI seu código controlador pode ficar assim:

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

Quando seus requisitos mudam dizer, em vez de Google Drive você está convidado a usar o Dropbox. Você só precisa escrever uma aplicação Dropbox para o StorageServiceInterface. Você não tem efectuar quaisquer alterações no controlador enquanto implementação Dropbox adere ao StorageServiceInterface.

Durante o teste você pode criar a falsa para o StorageServiceInterface com a implementação fictícia onde todos os métodos retornam nulo (ou qualquer valor pré-definido de acordo com sua exigência de teste).

Em vez disso, se você tivesse a classe controller para construir o objeto de armazenamento com a newpalavra-chave como este:

class SomeController
{
    private $storage;

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

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

Quando você quer mudar com a implementação Dropbox você tem que substituir todas as linhas onde newGoogleDriveService objeto é construído e usar o DropboxService. Além ao testar a classe SomeController o construtor espera sempre a classe GoogleDriveService e os métodos efetivos desta classe são acionados.

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

Respondeu 04/11/2017 em 13:27
fonte usuário

votos
4

Eu entendo que a resposta já foi dada aqui. Mas eu ainda acho que, algumas noções básicas sobre a inversão de controle tem que ser discutido aqui em comprimento para futuros leitores.

Inversão de Controle (IoC) foi construído sobre um princípio muito simples chamado Princípio Hollywood . E diz que,

Não ligue para nós, vamos chamá-lo

O que isto significa é que não vão para a Hollywood para realizar seu sonho, em vez se você é digno, em seguida, Hollywood vai encontrá-lo e fazer o seu sonho se torna realidade. Praticamente invertido, hein?

Agora, quando discutimos sobre o princípio da IoC, nós usamos a esquecer a Hollywood. Para IoC, tem de haver três elementos, um Hollywood, você e uma tarefa gostaria de cumprir o seu sonho.

Em nosso mundo de programação, Hollywood representam um quadro genérico (pode ser escrito por você ou alguém), você representam o código de usuário que você escreveu e a tarefa representar a coisa que você quer alcançar com o seu código. Agora você não precisa nem ir para desencadear a sua tarefa por si mesmo, não em IoC! Em vez de ter desenhado tudo em tal que o seu quadro irá desencadear a sua tarefa para você. Assim você construiu um quadro reutilizável que pode fazer alguém um herói ou um outro vilão. Mas esse quadro está sempre no comando, ele sabe quando deve escolher alguém e esse alguém só sabe o que quer ser.

Um exemplo da vida real seria dado aqui. Suponha que você quer desenvolver uma aplicação web. Então, você criar um quadro que irá lidar com todas as coisas comuns de uma aplicação web deve tratar como tratamento de solicitação http, criando menu do aplicativo, servindo páginas, gerenciar cookies, provocando eventos etc.

E então você deixar alguns ganchos em seu quadro onde você pode colocar outros códigos para gerar menu personalizado, páginas, os cookies ou registrando alguns eventos do usuário etc. Em cada solicitação do navegador, o seu quadro será executado e executa seus códigos personalizados se viciado, então, servir-lo de volta para o navegador.

Assim, a idéia é bastante simples. Ao invés de criar um aplicativo de usuário que irá controlar tudo, primeiro você cria uma estrutura reutilizável que irá controlar tudo, em seguida, escrever seus códigos personalizados e ligá-lo ao quadro para executar aqueles no tempo.

Laravel e EJB são exemplos de tais estruturas.

Referência:

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

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

Respondeu 01/10/2017 em 11:24
fonte usuário

votos
4

COI também é conhecida como injecção de dependência (DI). É um processo pelo qual objectos definir as suas dependências, isto é, os outros objectos com os quais trabalham, apenas através de argumentos do construtor, argumentos para um método de fábrica, ou propriedades que são definidas na instância de objecto depois de ser construído ou devolvido a partir de um método de fábrica . O recipiente em seguida injecta essas dependências, quando se cria o feijão. Este processo é fundamentalmente o inverso, daí o nome de inversão de controle (COI), da própria feijão controlar a instanciação ou localização das suas dependências usando construção directa das classes, ou um mecanismo, tal como o padrão de serviço localizador

Spring-framework-referance.pfd página 27 (se contar todas as páginas do documento pdf, é na página 51)

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/pdf/spring-framework-reference.pdf

Respondeu 24/01/2013 em 15:52
fonte usuário

votos
3

Inversão de controle é quando você vai ao supermercado e sua esposa dá-lhe a lista de produtos para comprar.

Em termos de programação, ela passou uma função de retorno getProductList()para a função que está a executar doShopping();

Ele permite que o usuário da função para definir algumas partes dele tornando-o mais flexível.

Respondeu 15/12/2017 em 18:35
fonte usuário

votos
3

Para entender o conceito, Inversão de Controle (IoC) ou inversão de dependência Princípio (DIP) envolve duas atividades: a abstração e inversão. Dependency Injection (DI) é apenas um dos poucos dos métodos de inversão.

Para ler mais sobre isso, você pode ler o meu blog aqui

  1. O que é isso?

É uma prática onde você deixar o comportamento real vem de fora do limite (Classe em Programação Orientada a Objetos). A entidade limite só conhece a abstração (por exemplo, interface, classe abstrata, delegado em Programação Orientada a Objetos) dele.

  1. Quais os problemas que ele resolve?

Em termos de programação, IoC tentar resolver código monolítico, tornando-modular, dissociando várias partes do mesmo, e torná-lo unidade testável.

  1. Quando é apropriado e quando não?

É adequado na maioria das vezes, a menos que você tem situação em que você só quer código monolítico (programa de exemplo muito simples)

Respondeu 03/06/2016 em 01:46
fonte usuário

votos
3

Criando um objeto dentro da classe é chamado acoplamento forte, Primavera remove essa dependência, seguindo um padrão de design (DI / IOC). Em que objecto da classe no passado no construtor, em vez de criar em classe. Mais sobre nós damos variável de referência super classe no construtor para definir a estrutura mais geral.

Respondeu 13/05/2015 em 08:52
fonte usuário

votos
3
  1. Assim, o número 1 acima . O que é inversão de controle?

  2. A manutenção é o número uma coisa que resolve para mim. Ela garante que estou usando interfaces de modo que as duas classes não são íntimos uns com os outros.

Em usando um recipiente como o Castelo de Windsor, que resolve problemas de manutenção ainda melhor. Ser capaz de trocar um componente que vai para um banco de dados para aquele que usa a persistência baseada em arquivo sem alterar uma linha de código é incrível (alteração de configuração, você está feito).

E uma vez que você entrar em genéricos, fica ainda melhor. Imagine ter uma editora mensagem que recebe registros e publica mensagens. Não importa o que publica, mas precisa de um mapeador para tirar algo de um registro a uma mensagem.

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

Eu escrevi uma vez, mas agora eu posso injetar muitos tipos para este conjunto de código se eu publicar diferentes tipos de mensagens. Eu também pode escrever mapeadores que levam um registro do mesmo tipo e mapeá-los para mensagens diferentes. Usando DI com Generics deu-me a capacidade de escrever código muito pequeno para realizar muitas tarefas.

Oh sim, há preocupações de testabilidade, mas eles são secundários aos benefícios da IOC / DI.

Estou definitivamente amar IOC / DI.

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

Respondeu 19/09/2008 em 05:59
fonte usuário

votos
2

Usando IoC você não está new'ing de seus objetos. Seu contêiner IoC vai fazer isso e gerenciar a vida útil deles.

Resolve o problema de ter de alterar manualmente a cada instanciação de um tipo de objecto para outro.

É conveniente quando você tem uma funcionalidade que pode mudar no futuro ou que pode ser diferente, dependendo do ambiente ou de configuração usada.

Respondeu 16/07/2015 em 16:06
fonte usuário

votos
1

A primeira versão do Java EE (J2EE na época) introduziu o conceito de inversão de controle (COI), o que significa que o contêiner iria assumir o controle de seu código de negócios e prestação de serviços técnicos (tais como transação ou de gestão de segurança).

Respondeu 03/04/2017 em 22:42
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more