Refatorando o JForum - ajuda com a arquitetura

Atencao: A mensagem que se segue ficou um tanto grande, e nao cobre todos os pontos que gostaria. Portanto, ao inves de fazer um livro com as minhas duvidas, vou faze-las em partes, de acordo com o andamento do topico.

Atualmente, a logica de negocios do JForum esta basicamente nas actions - como "logica de negocios" aqui, por favor entendam coisas como verificacao de seguranca, validacao de parametros, definicao do contexto do freemarker e acesso aos DAOs. Ha bastante codigo em classes utilitarias tambem, as quais foram movidas para tais pois eram usadas em mais de um lugar. Nao vou entrar em detalhes de implementacao por nao haver mta necessidade.

Para sair dessa meleca, comecei a refatorar o JForum. A cada hora que passa vejo cada vez mais que estou a ponto de reescrever uma enorme parte do codigo fonte. Embora o codigo atual esteja limpo e, principalmente, facil de entender e manter, falta pouco para um limite da arquitetura, onde entao ficara muito dificil adicionar coisas novas sem prejudicar a estabilidade do sistema (aka, falta de testes da nisso).
Conversando com o Villela e dando uma lida no PoEAA, GOF e Core J2EE Patterns (fora material da net), acabei ficando com muitas duvidas em relacao a como fazer o refactoring. De uma maneira ampla, alem dos ja citados elementos "extensiblidade" e "testabilidade", faz-se necessario ter uma API de servicos, afim que seja possivel interagir com o JForum usando meios outros que somente um browser.

Tendo isso em mente, o que tenho (praticamente) definido eh assim:

As actions somente irao interagir com os servicos, e fazer coisas especificas ao ambiente - no caso de web / browser normal, eh configurar o contexto do sistema de templates / criar objetos a serem passados aos servicos.

Sobre "servico" eu entendo como um conjunto de metodos que servem como ponto de entrada / delegadores para a camada de negocios.

Ai comecam a pintar as maiores duvidas, sendo um tanto dificil achar um ponto de partida. Vou explicar o que comecei a fazer, tentar dar alguma justificativa, e esperar que alguem aqui tenha uma boa ideia. A primeira ideia que eu tive foi, obviamente, tirar todo codigo "de negocios" das actions, e mover para classes de servico, como PostService, TopicService e etc.. tais classes verificam se o usuario tem direito de execucao na tarefa, se o topico solicitado existe, e entao chamam os metodos dos DAOs para fazer a persistencia. Simplificando o codigo, fica algo como

Ou seja, o servico se encarrega de cuidar das dependencias e tudo mais. Porem, esse codigo nao esta me agradando muito, pois ainda parece um codigo bastante tanto acoplhado e especialmente fragil. O cv sugeriu usar listeners e mover boa parte da logica para os pojos, formando assim um domain model (ou algo parecido com isso). Indo por esse lado, o codigo anterior resultaria nisso:

Define o listener

Classes que precisam ser notificadas sobre alteracoes em posts implementam-a

O mesmo para o topico

A classe de post se encarrega de notificar todo mundo

Os observers sao registrados no startup do sistema

Removendo uma mensagem.

A BEM grosso modo eh isso. Nao tenho uma implementacao concreta, mas tenho varias duvidas. Dicas gerais sobre formas de estruturar o codigo, responsabilidades e tudo mais sao muito bem vindas.

Rafael

Bom, acho que eu nem tenho muito a adicionar aqui... mas pq vc tem uma interface pros DAOs? Se, a principio, vc so tiver uma implementacao, use a impl direto (dado que o seu model nao vai usar o DAO diretamente, ele so vai notificar um Listener - que por acaso eh um DAO). Assim voce evita classes com nomes medonhos do tipo FooImpl ou ConcreteFoo

cv wrote:Bom, acho que eu nem tenho muito a adicionar aqui... mas pq vc tem uma interface pros DAOs? Se, a principio, vc so tiver uma implementacao, use a impl direto (dado que o seu model nao vai usar o DAO diretamente, ele so vai notificar um Listener - que por acaso eh um DAO). Assim voce evita classes com nomes medonhos do tipo FooImpl ou ConcreteFoo

E depois se precisar trocar a impl faz um refactoring no código todo...??? Eu tenho opinião contrária... Eu acho q devia continuar com as interfaces....

O que tem de tao dificil em UM extract interface, Eduardo?

Soh existe UM DAO???
E pq não fazer do "jeito correto" logo??? Qual e a vantagem de fazer o extract interface depois?

Nao eh taaao importante assim, mas o ponto eh que, se vc vai ter uma interface com uma unica implementacao, entao pra que a interface? "Ah, eu posso ter uma outra implementacao qualquer dia desses"? Se esse dia nao chegar, vc programou a toa

E se esse dia chegar?

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

simples.. vai lá e muda!!!

Se esse dia chegar vc perde os 5 minutos que vc precisa pra dar os extract interface nos lugares necessarios, e implementa os novos DAOs, ueh! Voce vai ter que revisar as interfaces de qualquer jeito, pq fatalmente a nova implementacao vai ter alguma diferencazinha que vc vai ter que acomodar pra cobrir todos os casos sem fazer muito esforco.

XP, XP, XP é isso que o CV ta tentando dizer.
Faca o que precisa hoje, se um dia precisar mudar algo vai la e muda. Ou seja se precisar de um DAO novo extract interface, enquanto esse dia nao chega deixa o sistema com uma interface a menos.

]['s

This message was edited 1 time. Last update was at 11/04/2005 11:24:47

Pelamordedeus.. voces tao brigando por causa dos daos?

Eu tenho interfaces para eles pq nao uso Hibernate e preciso suportar diversas fontes de dados (suporta ja mysql, hsqldb, postgresql, oracle e sqlserver).

Nao, uma migracao para hibernate nao esta nos planos no momento

Rafael

btw: eh MySqlForumDAO, OracleForumDAO etc.. mas isso quem me traz eh o abstract factory.

Ah nem...
Acho que é muito estilo de programação isso aqui... Cada um acha melhor do seu jeito... Eu prefiro abstrair e esconder atrás de interfaces desde o primeiro momento...
Sejam felizes aqueles que nâo gostam

Mas sei lá, acho que programar classes sem interfaces eh menos OO do que programar com interfaces...
Talvez seja purismo demais, mas eu gosto do código com mais interfaces (sem exageros, mas eu acho que no caso de daos se justifica sim)...

T+

Rafael Steil wrote:Pelamordedeus.. voces tao brigando por causa dos daos?

Eu tenho interfaces para eles pq nao uso Hibernate e preciso suportar diversas fontes de dados (suporta ja mysql, hsqldb, postgresql, oracle e sqlserver).

Nao, uma migracao para hibernate nao esta nos planos no momento

Rafael

Brigando nada! Eh soh uma discussãozinha bem construtiva...

T+

Bom, nesse caso, voce ja TEM mais de uma implementacao. Caso encerrado

duardor wrote:Mas sei lá, acho que programar classes sem interfaces eh menos OO do que programar com interfaces...

Em Smalltalk, uma linguagem que ninguem aqui discorda que eh 100% OO, nao existem interfaces. E ai, como fica?

O ponto eh que interfaces sao soh contratinhos que vc coloca na frente das suas classes. Eh o jeito que o Java arrumou pra fazer heranca multipla, mas nao eh algo OBRIGATORIO, ou que deveria te deixar desconfortavel. Se nao precisar ter, nao precisa ter, e pronto. Menos codigo pra escrever, documentar, depurar e manter

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