IoC - Inversion of Control?

Que eu saiba, IoC não é um pattern. É um paradigma.

Um pattern, AFAIK (adoro essas siglas ridículas), é uma solução famosa para um problema.

Pra entender IoC, eu precisei primeiro entender o que eles chamam de componente. Um componente é um objeto que provê serviços numa aplicacao. No caso de um objeto Java, esses serviços são os métodos.

IoC diz que vc deve fornecer para um componente, logo no construtor, tudo o que ele precisa pra rodar. Provavelmente, serao opcoes de configuracao e outros componentes dos quais ele dependa.

Nada de chamar new dentro do construtor do componente!!

Essa é, bem por cima, a idéia. Mas eu acho que esse é um caso de : por mais que alguém tente te explicar, vc vai acabar entendendo é sozinho. E tb nao vai conseguir explicar pros outros… : )))

[]s!!

Sendo um pouquinho chato aqui - IoC nao diz que vc deve fornecer tudo que o componente precisa logo na construção do objeto (e não no construtor, isso é estratégia de implementação do Pico). Quem faz esse trabalho é o container de IoC.

Essa ideia nem é tão difícil de se acostumar. Lembra-se daquela regrinha de “nada de dar new num EJB”? Mesma coisa aqui - aliás, um conteiner de EJBs é um conteiner de IoC.

Talvez isso diferencie um paradigma… aconteceu isso comigo quando eu estava aprendendo OOP, AOP, e IoC tambem

Hum, beleza! Puxa, até de pattern eu chamei :oops: .

O problema é que o que tenho encontrato falando sobe isso tem sido muito vago. O que me confunde é até onde é IoC nos exemplos que vejo.

E quanto ao lance da fábrica generica que tinha mensionado, vejo que estou confundindo o picoContainer com o IoC. Agora passo a achar que o IoC é aplicado para os componentes que o pico vai criar. Bem, não sei se estou falando besteira novamente. :shock:

A idéia de fábrica genérica é bem interessante. A regra geral (se é possível dizer isso) para IoC é que um componente nunca corre atrás dos demais componentes que ele precisa para sua instanciação. Ao invés disso, o componente pede a alguém (o container) tudo o que ele precisar e o container tenta de alguma forma suprir as necessidades do componente. Eu costumo chamar isso de “pattern do componente mimado”.

HUAUHAUHAUHAUHA

Se vc for ver, eles sao mimados ateh demais… um componente, por exemplo, consegue ter gerenciamento de ciclo de vida, seguranca, transacoes, distribuicao, dependencias, logging, caching, e todos aqueles outros aspectos que a gente sempre acha que precisa FORA DO CODIGO DO COMPONENTE… entao, quem faz o componente de processamento de boleto bancario se preocupa com a logica de negocio, e mais nada. Quem faz componente de bancos de dados se preocupa com os bancos de dados, e mais nada… e por aih vai

eu ouvi gente falando do pico container, alguem recomenda outra?

o avalon! é ponto apache.org

Conteiners de IoC:

Tipo 1: Avalon

Tipo 2: XWork, Spring

Tipo 3: PicoContainer, NanoContainer

Tipo 4: NotAContainer

(mais tarde eu volto aqui nesse post e coloco umas URLs, mas eu vou confiar que vcs sabem usar o gooooooogle ;))

“cv”:

Conteiners de IoC:
.
.
.
Tipo 4: NotAContainer

(mais tarde eu volto aqui nesse post e coloco umas URLs, mas eu vou confiar que vcs sabem usar o gooooooogle ;))

Putz!! Vou ressuscitar este tópico com bastante atraso. Tenho usado o NotAContainer em algumas brincadeirinhas com IoC e NotAContainer é animal. Para as coisas que eu tenho precisado, o NAC tem caído como uma luva para os projetos que eu tenho feito.

Agora que o tio Martin Fowler renomeou o IoC, vale a pena dar uma ressuscitada nesse post. Seguinte, joguem a listinha anterior fora; ela ficou assim, agora:

Dependency Injection (Injecao de Dependencias):

Type 1 = Interface Injection
Type 2 = Setter Injection
Type 3 = Constructor Injection

Estao pipocando diversos outros containers por ai, e o Pico agora pode ser usado tanto para injecao de interfaces, setters ou construtores, atraves de ComponentAdaptors. O projeto Jicarilla ( http://jicarilla.sourceforge.net/ ) tambem esta fazendo progressos bastante interessantes, e vale a pena ficar de olho