Oi pessoal, gostaria de fazer uma pergunta para vcs sobre o pattern IoC. Estive dando uma olhada nas explicações do projeto avalon sobre o IoC mais não compreendi bem o conceito. Quando vejo os exemplos de implementação fico achando que não passa de usar uns tipos de fábricas genéricas para localizar e criar objetos. É por isso que estou perguntando sobre isso aqui pois sempre me digo, “não é isso seu burro!”.
É que trabalho com uma arquitetura onde todos os objetos são acessados por suas interfaces e criados por fábricas no padrão Factory do GoF. Então quando olho para os exemplos de IoC como o HiveMind ou PicoContainer, fico pensando: “Legal não preciso criar mais as danadas das fábricas!”.Mais no meu íntimo eu penso tb: “será que é isso mesmo?”.
Bem, agora fica minha dúvida para os amigos do GUJ.
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… : )))
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”.
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
[quote=“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 ;))[/quote]
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
- aliás, um conteiner de EJBs é um conteiner de IoC.