:: Google Guice, Google DI Framework

De um jeito ou de outro tem uma dependencia....

É impossivel você reusar algo q alguem fez sem criar algum tipo de depencia....

Antes uma fisica (implementar ou extender algo) do q uma metafisica (ah, o metodo tem q ser void, tem q receber como parametro xyz, tem q ter um atributo privado na classe chamado JJJ, etc)

E eu prefiro uma dependencia compilável do que uma não compilável! (Jogar dentro de um XML já era compilação, reflexão tbm)

VELO

saoj wrote:Para o metodo configure() sem problemas. Mas dentro desse metodo vc vai ter que chamar outros metodos para configurar a coisa, e esses metodos tem que vir de algum lugar. CoC nao resolve aqui...

Sérgio, não entendi a parte em negrito. Pode dar um exemplo com código?

Não acho que o Guice e o Spring sejam tão concorrentes assim. Afinal o Spring é uma stack para a criação de aplicações enquanto o Guice é apenas um framework para DI. Entendi alguma parte errado?

valeuz...

jack_-_ganzha wrote:

saoj wrote:Para o metodo configure() sem problemas. Mas dentro desse metodo vc vai ter que chamar outros metodos para configurar a coisa, e esses metodos tem que vir de algum lugar. CoC nao resolve aqui...

Sérgio, não entendi a parte em negrito. Pode dar um exemplo com código?

Opcoes:

1) Heranca

2) Parametro

3) Classe estatica (ruim demais)

Eu prefiro disparado a opcao 1).

Acho que criou-se um preconceito contra heranca injustificavel.

Dentro do seu modelo de negocios e entidades ela deve ser usada com parcimonia, talvez ate ser evitada em prol de composicao.

Mas quando temos actions, modulos, e essas outras coisas do framework para o framework, nao ha porque nao usar heranca.

Há sim: testabilidade e desvínculo do framework e da infra-estrutura, acoplamento, coesão e cogeneridade. Além disso herança dificilmente faz sentido fora de uso polimórfico num ponto de vista meramente técnico.

Mas voltando ao caso específico, eu não entendi seu exemplo. Vamos supor que eu tenha um módulo A que dependa de um módulo B.

Eu posso simplesmente utilizar metadados:

pseudocodigo:

Bem parecido com EJB 3.0.

É exatamente assim que o spring funciona, com configuração em metadados (se são XML ou pqp é outro papo). Fazer o módulo depender do framework é uma das principais falhas do Struts, por exemplo.

Note que se você precisa dar o bind de um componente num objeto qualquer você não está usando IoC, está usando Registry. Quem faz isso é o container.

Ou seja, ao invez de atrelar com uma classe atrela com um monte de annotations?

VELO

pcalcado wrote:Há sim: testabilidade e desvínculo do framework e da infra-estrutura, acoplamento, coesão e cogeneridade.

Com esse codigo cheio de anotacoes isso que vc falou ai em cima ficou contraditorio. Ou nao?

Usar uma coisa sem se atrelar a ela, me parece overkill, ou seja, perde-se muito e ganha-se pouco.

O seu modelo de negocios junto com as suas entidades, esses sim, nao devem estar atrelados a nada.

pcalcado wrote:class MeuXyz extends AbsctractXyz??!?

É sério que as pessoas ainda constroem frameworks onde os módulos não são POJOs?

Achei que era so eu que nao tinha gostado daquela parada.

]['s

fabgp2001 wrote:

Achei que era so eu que nao tinha gostado daquela parada.

Soh falta agora apresentar motivos ne?

Vc prefere se atrelar a uma classe herdando ela e ganhando de presente um monte de funcionalidades ou usar anotacoes atrelando do mesmo jeito?

Mais uma vez repito: estamos falando aqui de actions, modulos, registars e por ai vai. Nao estamos falando de modelo de negocio e suas entidades, que eh claro pra todo mundo que nao deve se atrelar a nada. Vejam novamente a classe MyModule e reparem que ela eh uma coisa do framework para ser usado com o framework e nada mais. Assim como um arquivo XML e as anotacoes o sao...

Acho que temos um anti-pattern aqui. Pegaram a heranca como bode-espiatorio...

saoj wrote:
Com esse codigo cheio de anotacoes isso que vc falou ai em cima ficou contraditorio. Ou nao?

Sim e não.

Meu código não depende de absolutamente nada do framework, o que o deixa compeltamente desacoplado.

Um possível problema seria metadados. Metadados não deveriam ser considerados como vínculo entre um framework e um objeto, mas eu acredito que anotações estaticamente etipadas como as de Java são um problema.

Ainda não consegui dimensionar isso em um modelo real, então não tenho conclusões, mas o problema de um framework não-POJO como o que você citou eu e toda a comunidade já conhecemos há alguns anos, por isso surgiram Spring, EJB3.0, Java EE 5.0, Struts 2, etc, etc, etc

saoj wrote:
Usar uma coisa sem se atrelar a ela, me parece overkill, ou seja, perde-se muito e ganha-se pouco.

Então todo conceito de POJo é overkill para você

Recomendo fortemente a leitura dos livros de Rod Johnson, Eric Evans e Bruce Tate.

saoj wrote:
O seu modelo de negocios junto com as suas entidades, esses sim, nao devem estar atrelados a nada.

Isso merece uma explicação com um pouco mais de contexto. Page-Jones define os domínios de um sistema (nada aver com Domain Model), entre eles temos Negócios e Aplicação.

O código de negócios seria aquele que mapeia as entidades do mundo real. O código da aplicação mapeia as operações que aqueles casos de uso realizam sobre estes objetos.

Os tais módulos dificilmente (a menos que num plugin para MVC, persistência ou sei lá) saem destes dois domínios e estes são os mais importantes apra uma aplicação.

Bem, como código importante ele deve ser testado, certificado, facilmente refatorável, flexível e uma outra pá de adjetivo. Se você vincula este código com um framework você perde boa parte destes.

saoj wrote:

fabgp2001 wrote:

Achei que era so eu que nao tinha gostado daquela parada.

Soh falta agora apresentar motivos ne?

Vc prefere se atrelar a uma classe herdando ela e ganhando de presente um monte de funcionalidades ou usar anotacoes atrelando do mesmo jeito?

Acho que temos um anti-pattern aqui. Pegaram a heranca como bode-espiatorio...

A herenca ali naquele caso não passa de um heranca pra economia de codigo o que eu acho feio e não gosto. Outra coisa porque AbstractModule tem que ser abstrata? Porque nao fazer igual o Hibernate faz com a classe Configuration?

Outra coisa ao invez de obrigar a fazer isso podiam ter uma configuracao automatica tipo o VRaptor faz com os components.

Questao de opinao.

]['s

Unica explicacao para nao querer atrelar nada a sua action seria porque vc esta codificando seu modelo de negocios DENTRO da action, o que eh totalmente errado.

A action nao eh codigo importante, na grande maioria das vezes eh apenas uma ponte para o modelo de negocios. E nada te impede de testar uma action, estando ela atrelada ou nao a uma classe pai. Isso jah foi mostrado, provado e discutido um milhao de vezes, mas enfim...

E um modulo de configuracao programatica nao existe para ser testado. Nao faz o menor sentido testar ele assim como nao faz o menor sentido testar um arquivo properties ou XML.

De novo. Action e Configuracao eh uma coisa. Modelo de negocios, DAOs e entidades sao outras completamente diferentes.

Action apesar de algo burro e simples, vc pode testar FACILMENTE E SEM QUALQUER PROBLEMA, mesmo que ela seja atrelada a uma classe pai.

ApplicationManager nao foi feito para ser testado, mas se o cara eh caxias entao ele pode testar tb e publicar um blog interessante sobre isso. "Como testar se sua configuracao tem bug!"

O problema do Struts nao era por que ele extendia uma BaseAction, eu e todos da comunidade sabemos que os problemas eram outros...

Mas eh um questao subjetiva, uma discursao sobre teoria e pratica.

Olha que engraçado, herdar não era problema para o Struts? A apache discorda de você:

http://struts.apache.org/2.x/docs/comparing-struts-1-and-2.html wrote:
Action classes

Struts 1

requires Action classes to extend an abstract base class. A common problem in Struts 1 is programming to abstract classes instead of interfaces. An Struts 2 Action may implement an Action interface, along with other interfaces to enable optional and custom services. Struts 2 provides a base ActionSupport class to implement commonly used interfaces. Albeit, the Action interface is not required. Any POJO object with a execute signature can be used as an Struts 2 Action object.

E que comunidade é essa que você frequenta? Uma busca no Google traz uma mar de resultados...

http://mail-archives.apache.org/mod_mbox/struts-dev/200503.mbox/%3Ce03014300503160640641b19a2@mail.gmail.com%3E
http://raibledesigns.com/rd/entry/how_do_you_get_around
http://72.14.209.104/search?q=cache:9LMizODEbkYJ:strecks.sourceforge.net/docs/Struts-Extensions-20032006.pdf+struts+problems+pojos+inheritance&hl=en&ct=clnk&cd=20
http://www.theserverside.com/tt/articles/article.tss?l=StrutsforJava5
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/2/30112/01381270.pdf?arnumber=1381270
...

E quais os problemas reais? XML?

saoj wrote:
Unica explicacao para nao querer atrelar nada a sua action seria porque vc esta codificando seu modelo de negocios DENTRO da action, o que eh totalmente errado.

Releia a parte de domínios acima, consulte a bibliografia ou pelo menos dê argumentos, por favor.

Segundo seu pensamento TDD é uma burrice sem tamanho, já que vai querer que você pense nas actions com testes antes de implementação. Além do que a grande vantagem em definir actions como POJOs é que você pode utiliza-las fora do framework, logo elas não rpecisam ser burras.

Se minha Action é um POJO, completamente testado e que nem sequer precisa seguir o padrão Command por que eu não posso simplesmente fazer minha aplicação web conversar diretamente com o Service Façade?

saoj wrote:
A action nao eh codigo importante, na grande maioria das vezes eh apenas uma ponte para o modelo de negocios. E nada te impede de testar uma action, estando ela atrelada ou nao a uma classe pai. Isso jah foi mostrado, provado e discutido um milhao de vezes, mas enfim...

Ver resposta acima.

Claro, por exemplo testar uma Action Struts é muito fácil, inclusive por isso toda a comunidade java continua seguindo este modelo e rindo de coisas inúteis como o Spring.

O que esse tal módulo faz, afinal? Bind de componentes para nomes? Isso não é papel do container?

Para mim mais uma vez você está ignorando a evolução de anos de uma plataforma, voltando para uma característica que sempre foi um dos grandes problemas de EJB 1.x/2.x, Struts e todos os 'frameworks de primeira geração'.

Toda essa teoria bonita vai ter um preco: complexidade.

Se vc quer criar uma aplicacao web totalmente desacoplada de qualquer framework e totalmente acoplada a um monte de annotations, se vc quer criar um modelo de negocios que por magica (magica = um monte de anotations e convencoes loucas) ele se torne uma aplicacao web, vc pode.

O que vc vai ganhar com isso alem de tirar onda com os amigos de que sua aplicacao eh a mais puritana possivel e segue os conceitos do livro de patterns de Michael Zimmerman e Oswald Anthony? Muito pouco! Isso na minha opiniao.

Vamos a pratica que eh o que interessa no final das contas, ou nao?

Claro que dah para fazer tudo isso via magica, convencoes e annotations. Eu acho que o preco a pagar eh o aumento da complexidade e o que se ganha no final das contas eh pouco, visto que o seu modelo de negocios vai estar em outro lugar e nao ai dentro.

Mas isso eh apenas a minha opiniao e entendo e aceito que outras pessoas poderao pensar diferente. Estou apenas me apegando ao principio de que SIMPLICIDADE eh o mais importante. Outras pessoas nao necessariamente precisam concorda com esse principio.

Pelo menos foi legal ver que nao estou sozinho, que o Guice tb usa um esquema parecido de configuracao programatica.

Unica explicacao para nao querer atrelar nada a sua action seria porque vc esta codificando seu modelo de negocios DENTRO da action, o que eh totalmente errado.

Claro que dah para fazer tudo isso via magica, convencoes e annotations. Eu acho que o preco a pagar eh o aumento da complexidade e o que se ganha no final das contas eh pouco, visto que o seu modelo de negocios vai estar em outro lugar e nao ai dentro.

Fala Amigo, tudo bem?

Então, estou acompanhando essa discução e vi essas duas mensagens que vc postou... eu entendi errado ou vc disse na primeira que codificar o modelo de negócios dentro da action é errado e na segunda vc disse o inverso? Sem sacanagem, só não entendi mesmo... oque vc quis dizer na primeira e oque vc quis dizer na segunda?

[]'s

Desdenhar um argumento com "teoria bonita" só mostra que não vale a pena continuar esse pseudo-debate.

Desprezar décadas de teoria de ciência da computação já é ridículo.

Ignorar o fato de que existem zilhões de ferramentas que fazem tanto sucesso que revolucionaram a maneira como as coisas são feitas (Spring, RoR, Hibernate, EJB 3, etc.) é simplesmente lamentável.

Chamar isso de complexidade sem qualquer argumento é simplesmente uma prova de que você nunca viu ou testou a fundo estas plataformas. Coloca SIMPLICIDADE em caps não vai trazer qualquer argumento ao debate alémd e chamar a atenção para uma não-verdade.

As suas perguntas no trecho de código mostram que ainda te falta compreender como as coisas funcionam em Injeção de Dependências (como eu obtenho recursos em DI?). Acreditar que uma action deve saber o que é POST ou GET é sintoma de incapacidade de abstração.

Como não foram dados quaisquer argumentos que não 'isso é complexo, bobo e feio' eu paro por aqui. Você é um desenvolvedor excelente, sérgio, mas cuidado com NIH, está atingido níveis patológicos.

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