Eh, eu sei que é muito bonito, desenhar o software utilizando-se o padrão IoC, como uma forma de se prevenir, na maioria das vezes com DI. Mas, na prática, já teve alguma situação onde, de fato, você teve que inverter o controle de algum artefato ? Cite esta situação 
[quote=MrDataFlex]Eh, eu sei que é muito bonito, desenhar o software utilizando-se o padrão IoC, como uma forma de se prevenir, na maioria das vezes com DI. Mas, na prática, já teve alguma situação onde, de fato, você teve que inverter o controle de algum artefato ? Cite esta situação
[/quote]
Imagine que vc vai desenvolver da seguinte forma:
1-criar uma interface.
2-criar um teste unitario para a interface (que depois tera a classe de implementacao injetada).
3-criar a classe que implementa a interface.
4-testar se sua classe de impl esta correta.
se nao fosse Ioc/DI ficaria meio complicado escrever o teste unitario sem ter a classe (implementacao) feita.
Esse é um exemplo de como utilizar ioc/di em testes unitarios… 
Exatamente,
IOC ajuuda muito na hora de testar… o teste unitário não precisa interagir com os objetos reais da aplicação, e IOC é uma maneira muito boa de contornar essa situação para utilizar mocks e stubs.
[]s
[quote=rlazoti][quote=MrDataFlex]Eh, eu sei que é muito bonito, desenhar o software utilizando-se o padrão IoC, como uma forma de se prevenir, na maioria das vezes com DI. Mas, na prática, já teve alguma situação onde, de fato, você teve que inverter o controle de algum artefato ? Cite esta situação
[/quote]
Imagine que vc vai desenvolver da seguinte forma:
1-criar uma interface.
2-criar um teste unitario para a interface (que depois tera a classe de implementacao injetada).
3-criar a classe que implementa a interface.
4-testar se sua classe de impl esta correta.
se nao fosse Ioc/DI ficaria meio complicado escrever o teste unitario sem ter a classe (implementacao) feita.
Esse é um exemplo de como utilizar ioc/di em testes unitarios… [/quote]
bom sou newbie no assunto então posso perguntar sem medo, isso que vc falou não se refere somente ao uso de interface? afinal não vejo porque eu precisaria de IOC pra programar testes para uma interface… IOC não entraria na flexibilidade de poder alterar as dependecias como por exemplo, injetar dentro da classe de teste a implementação de uma interface? nao intendi a complicação em escrever o testo unitaro se não fosse Ioc/DI que vc falou… como ioc/di me facilitaria escrever o codigo?
thnx.
[quote=MrDataFlex]Eh, eu sei que é muito bonito, desenhar o software utilizando-se o padrão IoC, como uma forma de se prevenir, na maioria das vezes com DI. Mas, na prática, já teve alguma situação onde, de fato, você teve que inverter o controle de algum artefato ? Cite esta situação
[/quote]
Inversão de Controle ( IoC) e Injeção de Dependencia (DI) são coisas diferentes. DI só pode ser usado se existir IoC.
Mas IoC pode existir mesmo sem DI. IoC é um corlário direto do Principio de Separação de Responsabilidades ( SoC)
Quando você cria um construtor com parâmetros isso é IoC.
Quando você coloca informações no seu web.xml isso é IoC.
Quando vc usa padrões de projeto, a maior parte das vezes , vc está usando IoC (todas as Factory, template method , Builder , pro exemplo).
Acho que seria mais fácil perguntar quando vc não usa e IoC ( em programa bem estruturado , claro)
Exemplo:
class Feirante{
private Barraquinha brqnh = new BarraquinhaDeumPavimento();
}Seu sistema mudou. O feirante enricou e agora possui uma barraca um pouco maior. Se você usasse injeção de depdendências basta mudar a confiuração do container, do contrário vai editar 300 arquivos de código fonte.
E se a barraquinha precisar ser transacional? Com IoC o seu container pode retornar uma instância já injetada com AOP. Se você fizer na mão vai ter algo como:
class Feirante{
private Barraquinha brqnh = new BarraquinhaQueEhTransacional(new BarraquinhaDeumPavimento());
}Em todo lugar.
Estes foram exemplos bobos mas este tipo de situação acontece o tempo todo em projetos. Gerenciamento de dependências em java é como se você pudesse fazer overload do operador new e ter controle sobre quem depende do quê.
Se é um exemplo prático da vida, aqui lá vai:
A empresa onde eu trabalhava, tinha uma classe Alarme. A idéia dessa classe é olhar alguns valores, ver se está dentro de parâmetros definidos e, se não tiver, tomar uma atitude. E qual era essa atitude? Bom, inicialmente era mandar um e-mail. Então lá vai criar a lógica de e-mail e alterar a classe Alarme para referenciar essa lógica.
Depois precisou de um caso que não era mandar por e-mail, era pra mandar por um outro protocolo que não lembro. Daí foi-se abrir a classe alarme para referenciar a lógica do outro protocolo.
Ah! Aí precisou fazer uma ação que…
Bom, vocês já entenderam. Se naquela situação (quando ocorresse uma situação inesperada na classe Alarme), chamasse um método de uma interface chamada Aviso, nunca precisaria abrir a classe Alarme para fazer modificações. Bastaria criar uma nova classe que implemente Aviso, e setá-la num novo objeto de Alarme.