Minimizando impactor futuros em alteracoes no sistema

Ola,

Ando lendo alguns livros muito bons sobre engenharia de software, mas uma coisa ainda nao consegui responder.
O que poderia ser feito par minimizar que a adicao de um novo campo (que aparecera na interface) necessite de mundancas em praticamente todas as camadas (interface, modelo, persistencia).

Acho que nao tem jeito nao ne?? Nesse caso temos que sair mexendo por tudo, certo?

Abracos

Hm, usando Hibernate e alguns métodos espertinhos na interface para popular os objetos antes de enviar para o server, normalmente basta adicionar o campo na interface e a propriedade no objeto.

[quote=pen_fold_uk]Ola,

Ando lendo alguns livros muito bons sobre engenharia de software, mas uma coisa ainda nao consegui responder.
O que poderia ser feito par minimizar que a adicao de um novo campo (que aparecera na interface) necessite de mundancas em praticamente todas as camadas (interface, modelo, persistencia).

Acho que nao tem jeito nao ne?? Nesse caso temos que sair mexendo por tudo, certo?
[/quote]

Não. Se o seu sistema necessite ser dinamico use metadados e HashDTO. Use Proxies dinamicos para criar objetos com itnerfaces especiais, se necessário. O ponto é que se o campo é adicionado ele automaticamente aparece em todas as camadas. As camadas têm que saber reagir a isso.

Obrigado pessoal,

Sergio, isso seria algum pattern?

Se eu tiver usando EJB3, JPA e JSF (por exemplo).
Pelo que voce descreveu eu precisaria apenas adicionar a nova coluna no BD??
E adicionar o novo campo na respectiva tela?

desculpe, nao entendi muito bem seu exemplo. Sabe de algum material online que exemplifica essa sua solucao??

Muito obrigado

[quote=pen_fold_uk]Ola,

Ando lendo alguns livros muito bons sobre engenharia de software, mas uma coisa ainda nao consegui responder.
O que poderia ser feito par minimizar que a adicao de um novo campo (que aparecera na interface) necessite de mundancas em praticamente todas as camadas (interface, modelo, persistencia).

Acho que nao tem jeito nao ne?? Nesse caso temos que sair mexendo por tudo, certo?

Abracos[/quote]

Faça um bom design e mantenha seus testes unitários ou similares atualizados.

Literatura a respeito:

[quote=pen_fold_uk]Obrigado pessoal,

Sergio, isso seria algum pattern?

Se eu tiver usando EJB3, JPA e JSF (por exemplo).
Pelo que voce descreveu eu precisaria apenas adicionar a nova coluna no BD??
E adicionar o novo campo na respectiva tela?

desculpe, nao entendi muito bem seu exemplo. Sabe de algum material online que exemplifica essa sua solucao??

[/quote]

como eu falei, as camadas tem que ser conscientes que os campos podem ser alterados. Por exemplo, as telas tem que mostrou ou não o campo. o DAO tem que mapear ou não o campo, etc…
Esta é uma tecnica de “hot deploy” de campos.
Se vc estiver usado EJB, JPA ou JSF é extreamente dificil implementar estas tecnicas. Esqueça o hot deploy.
Ai vai ter que ir pelo que o LIPE falou e refactorando todas as camadas onde necessário.

Rails faz isso de maneira bem simples.

Encapsule o que varia!

att,
Joel Lobo

Se o que vc quer é definir seus campos apenas uma vez, existe uma abordagem
chamada “naked objects” (=objetos pelados) que consiste em expor diretamente
uma visualização automática dos objetos de negócio.

A interface usuário não é programada separadamente como no pattern MVC.
O ambiente de runtime usa introspecção / reflexão para mostrar os dados
e funcionalidade dos objetos de negócio de maneira transparente.

Em Java, há duas implementações mais conhecidas: JMatter e NakedObjects.
Segue o link de entrada da Wikipedia:

[quote=pcalcado]
Rails faz isso de maneira bem simples.[/quote]
Eita, nem a interface precisa mudar?

Normalmente precisa sim. A exceção neste caso é quando se usa scaffolding.

Não sou o maior especialista em Rails do mercado, mas pelo que eu sei o scaffold serve só para situações muito simples, protipação ou para gerar o esqueleto (sendo que neste caso não resolve o problema). Não é algo para ser usado profissionalmente em produção, confere?

Confere sim.

Não porque a solução não fica profissional, mas sim porque dificilmente um requisito vai ser tão simples quanto o que o scaffold gera :slight_smile:

Obrigado pessoal!

Abracos