Interface + IoC versus Reflection

Estou com uma dúvida meio louca aqui:

Quando temos IoC através de uma interface como UserDAOAware, onde podemos injetar um UserDAO, temos algo assim:

Logo para cada coisa que se queira injetar, eu tenho que criar uma interface para tal.

Não seria mais fácil usar reflection ??? Com reflection eu posso descobrir se a classe tem o tal setUserDAO. Se tiver eu injeto se não tiver não injeto.

Com reflection posso até mesmo injetar diretamente num atributo privado.

Faz sentido isso ??? Ou a interface é necessária para dizer se a minha classe quer ou não ser injetada ??? Implementando um setUserDAO já não seria suficiente para indicar isso?

Não entendi exatamente a sua dúvida mas a resposta é: não faz sentido.

IoC não te obriga a usar interfaces.

Thread.start() Membro desde: 12/07/2005 12:46:51 Mensagens: 32 Offline

Concordo com você ....

Gosto de IoC pelo fato de que você nao precisa se preocupar em extender, instanciar e etc, o framework coloca lah p/ vc ...

injetar direto no atributo não me parece correto até porque como o framework vai saber em qual atributo injetar supondo q vc tivesse dois atributos do tipo UserDAO ...

O PicoContainer não te obriga a fazer isso ...
qual container de IoC vc tah usando?

noelrocha wrote:
injetar direto no atributo não me parece correto até porque como o framework vai saber em qual atributo injetar supondo q vc tivesse dois atributos do tipo UserDAO ...

Ué, dois atributos necessariamente precisam de dois nomes diferentes.

A minha dúvida é: IoC pode funcionar com reflection, injetando até mesmo diretamente num atributo privado ou é melhor que seja feito via Interface.

Depende de como for feita a configuração dos componentes
da uma olhada no pico container

Po, sergio, tu me decepciona desse jeito, pensei que vc ia dar uma olhada no Spring, como havia me dito

Eu não tenho certeza, mas acho que no falecido projeto Apache Avalon, as dependências eram injetadas desse jeito, usando interfaces. Mas os containers IoC 'modernos' (Spring, Pico, HiveMind) usam reflection sim, você não precisa declarar uma interface pra cada dependência. As interfaces surgem apenas como boas práticas, mas é perfeitamente possível usar classes que não estendem de interface alguma. Aliás, eu acho que os setters de dependências não deveriam sequer serem declarados em interfaces, pois estas representam na maioria das vezes funções de negócio, enquanto dependências são detalhes de implementação.

Quanto às diferentes formas de injeção de dependências, Martin Fowler escreveu um artigo interessante que explica bem três formas de injeção - por construtores, por setters e por interfaces -, que há algum tempo atrás eu traduzi para o português.

Eu lembro de ter lido em um blog no java.net (faz tempo), de uma outra forma de injeção, a getter injection (!). Essa abordagem também é bastante interessante, apesar de ser meio viajante

Consistiria em declarar getters (abstratos ou que retornassem um valor default) para as dependências, que seriam sobrescritos pelo container, fazendo-os retornar as referências dos objetos injetados.

Uma grande vantagem que eu vejo nessa abordagem é que, ao contrário da setter injection (e das outras também), não haveria a necessidade de se criar métodos públicos para a injeção (como serão sobrescritos, os getters poderiam ser apenas protected), evitando 'sujar' a interface pública das classes.

Como desvantagem, eu penso que as pessoas já tem dificuldade o bastante para entender a injeção usando reflection simples, imagine usando herança com geração automática de bytecode (ainda mais 'indireto', a meu ver)! Outro ponto seria que, por essa abordagem, seria mais difícil usar o objeto sem um container (num test-case, por exemplo), já que os métodos injetores não são públicos. Você teria que estender cada classe para injetar a depenência (argh). Além disso, essa manipulação de bytecodes necessitaria de um framework adicional como a CGlib, BCEL ou Javassist, aumentando o número mínimo de jars empacotados junto da sua aplicação.

Bom, mas já estou viajando demais.... voltando à pergunta: dá pra alterar atributos privados via reflection, sem que o security manager do java reclame (sinceramente eu nunca tentei)? Via policies talvez... Mas isso seria recomendável?

Como eu já disse (e outras pessoas também) , não é preciso criar uma interface para injeção de dependências, pelo menos nos containers de Dependency Injection mais usados por aí. O uso de interfaces já foi utilizado no passado, mas acho que a morte desse projeto dá uma indicação de que a abordagem não foi muito bem aceita (também, credo, uma interface pra cada dependência???). Acessar diretamente atributos privados é perigoso, quebra completamente o encapsulamento e expõe suas classes a bugs indetectáveis (por exemplo, se você declarar um atributo privado que não deve ser injetado, que é um caso bastante comum, creio). Sobrescrever getters tem vantagens, mas não acho que elas acrescentem valor suficiente para ignorar as desvantagens.

Eu continuo 'partidário' da injeção via setters construtores, que não são tão invasivas ao código, não requerem malabarismos muito grandes (só reflection simples), não têm problemas com security managers, e são relativamente fáceis de compreender.

Ah, outra coisa, o Spring tem suporte a esse tipo de injeção por nomes, se você tem uma dependência "userDao" o Spring pode procurar o objeto que está definido com o "id" userDao. Lá isso é conhecido como "auto-wiring".

Contudo, entretanto, todavia, isso é terrivelmente sofrível porque o desenvolvedor vai terminar dando nome aos beans a partir da propriedade, ou pior ainda, vai botar o nome da propriedade pra ficar igual ao nome do "id" do bean. Eu, pessoalmente, acho isso uma prática horrível, prefiro que tudo fique amarrado de verdade, evitando confusões e nomes que não tem significado nenhum.

Mesmo para usar Autowiring voce precisaria declara beans, acho que o que o Sergio pensou e em injetar automaticamente, sem declarar nada (No XML, thanks :mrgreen

.

Sergio, sou mais um em dizer para olhar o Pico Container. Pela sua abpordagem, nao da para saber qual objeto deve ser injetado no container, convençoes de nomenclatura para este tipo de coisa sao horriveis (sim, eu conheço Rails e continuo achando horrivel te obrigar a programar do modo X ou Y por um detalhe), anotaçoes poderiam resolver mas eu ainda acredito que a grande vantagem do codigo feito pensando num IoC e que voce nao precisa se rpender ao Container. Se quem vai setar meu DAO e o Spring ou uma Factory, tanto faz (meu teste seta um mock na marra e o objeto testado nem liga).

Eu acredito que voce deva definir isso em outro lugar.

Alias, me ocorreu algo agora, mas vou abrir outro topico, esperem

pcalcado wrote:Eu acredito que voce deva definir isso em outro lugar.

Alias, me ocorreu algo agora, mas vou abrir outro topico, esperem

Cadê? Cadê? Cadê?

Maurício Linhares wrote:
Cadê? Cadê? Cadê?

Aqui, voce ja viu mas so rpa constar

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Shoes wrote:anotaçoes poderiam resolver mas eu ainda acredito que a grande vantagem do codigo feito pensando num IoC e que voce nao precisa se rpender ao Container

Opa.. acredito que este problema já está resolvido! O Sérgio já fez uma alteraçãozinha básico no Mentawai para que seja possível vc integrar o Mentawai com o container IoC que você quiser!!!

Fazer a integração com PicoContainer, Fábrica, Spring, HiveMind será tão fácil quanto tirar pirolito de criança!

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Thiago Senna wrote:

Shoes wrote:anotaçoes poderiam resolver mas eu ainda acredito que a grande vantagem do codigo feito pensando num IoC e que voce nao precisa se rpender ao Container

Opa.. acredito que este problema já está resolvido! O Sérgio já fez uma alteraçãozinha básico no Mentawai para que seja possível vc integrar o Mentawai com o container IoC que você quiser!!!

Fazer a integração com PicoContainer, Fábrica, Spring, HiveMind será tão fácil quanto tirar pirolito de criança!

Shoes, será que eu naum li sua pergunta direito e respondi merda?

Bom... de qualquer jeito, pelo menos o desenvolvedor se sentirá livre para escolher qual container IoC que ele deseja, e então integrá-lo com o Mentawai.

Com isso será possível vc injetar as dependências nas suas actions numa boa, seja via setter, via construtor, interface marcadora, clips, lacinhos vermelhos e etc....

This message was edited 1 time. Last update was at 21/07/2005 09:43:50

Valeu pelas dicas pessoal.

Acho então que vou oferecer no futuro todas as possobilidades de injeção. Interface Aware, Setter via reflection, e Atributo privado via reflection.

Acredito que o WebWork só oferece por interface.

E vejam que o Thiago está dando uma pesquisada na integração do Mentawai com outros containers de IoC, ou seja, ao gosto do freguês.

Interfaces, Interfaces, Interfaces. Acho que houve uma certa confusão aqui.

Significado 1:
Interface da sintaxe de java, correspontende às classes abstratradas com permissão de herança múltipla.

Exemplo:

Significado 2:
Interface de um componente, correspontende a todas possibilidades de interação.

Exemplo: para o componente "Televisão" tenho uma interface que me possibilita ligá-la, mudar de canal, etc.

Suponha que uma classe C tenha uma dependência D. Dessa forma, Para os containers IoC Spring e Pico:

Esta dependência D pode ser uma classe concreta, uma classe abstrata ou pode ser uma interface (siginificado 1).

C não precisa implementar uma interface Dware (siginificado 1) que exija um setter de um D.

C precisa ter uma interface (siginificado 2) para injeção da dependência D.

Em outras palavras, C não precisa ter implements Dware mas precisa implementar os métodos setters.

Tirar esta última exigência tá parecendo muito estranho. Acho que este é o tipo de situação onde anotação cai bem. Marcar os atributos que podem ser injetáveis.

Sergio, olha o PicoContainer. Ele prega a configuração programática de todos componentes.

Notícias, artigos e o maior fórum brasileiro sobre Java