Modelo Anêmico é realmente ruim?

This message was edited 1 time. Last update was at 07/04/2010 14:43:53

Estava pesquisando sobre modelo anêmico e todos falam que não se deve separar a parte de propriedades e funcionalidades do objeto.
Que criar objetos VOs e BOs é necessário somente em alguns casos.

Aonde trabalho a arquitetura da aplicação é toda feita entre VOs e BOs e tudo funciona muito bem e me parece bem organizado.

Agora a pergunta, se utilizar do modelo anêmico é realmente ruim? Utilizar um modelo rico é realmente mais vantajoso?

(Eu não estou afirmando que nem um e nem o outro é certo, estou perguntando a opinião de vocês sobre o que acham o mais correto)

Abraços

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 517 Offline

Frango wrote:Estava pesquisando sobre modelo anêmico e todos falam que não se deve separar a parte de propriedades e funcionalidades do objeto.
Que criar objetos VOs e BOs é necessário somente em alguns casos.

Aonde trabalho a arquitetura da aplicação é toda feita entre VOs e BOs e tudo funciona muito bem e me parece bem organizado.

Agora a pergunta, se utilizar do modelo anêmico é realmente ruim? Utilizar um modelo rico é realmente mais vantajoso?

(Eu não estou afirmando que nem um e nem o outro é certo, estou perguntando a opinião de vocês sobre o que acham o mais correto)

Abraços

Da mesma forma, nos tempos de Clipper nao havia orientacao a objetos e havia muitos bons softwares.

Um modelo anemico será necessariamente um fracasso? Nao, ele pode ser organizado e mesmo simples. Mas ele jamais terá a seguranca de um modelo de dominio bem feito, com os objetos respeitando suas responsabilidades e encapsulando o que nao deve ser mostrado ao mundo externo, so para citar um dos motivos de eu nao gostar dele. Ha outros.

Alem da diferença entre o seu conceito de organização e o meu conceito de organização. O seu conceito será formado pela comparação a outros codigos que voce já viu e considera organizado, que são diferentes dos códigos que eu já vi e considero organizado.

Resumindo minha opiniao, um modelo anemico pode até ter uma certa organização, facilidade de compreensao e de manutencao, mas sem duvida teria mais ainda tudo isso se nao fosse anemico.

Virtual Machine Man Membro desde: 14/09/2002 16:37:24 Mensagens: 698 Offline

Frango, esse modelo acadêmico eu entendo de certa forma como uma visão "conceitual" do domínio. Por exemplo: podemos usar isso em diagramas de classe para dizer quais são as operações daquele objeto e não necessariamente que a implementação do objeto terá tudo programado lá dentro.

Virtual Machine Man Membro desde: 14/09/2002 16:37:24 Mensagens: 698 Offline

como eu já tinha certo conhecimento disso, mas nao lembrava como aprendi.. resolvi dar uma pesquisada no assunto de Modelagem de dados, onde encontrei:

Modelo Conceitual:
Representação dos conceitos e características observados no ambiente;
Ignorar particularidades de implementação.

Vc conseque imprimir todos os fontes em 4 paginas A4 com fonte legal, legivel ?

Se sim o seu modelo é tão simples que qualquer forma que vc codifique-o, da mais procedural a mais OO, vai cumprir o seu papel. Porem se o seu modelo crescer (e geralmente cresce) a forma como vc estrutura os seu codigo se mostra mais ou menos eficiente para desenvolver, manter, testar, etc. Um modelo anêmico te traz este tipo de dificuldade.

Outra coisa é que ter um modelo mais proximo da realidade, com os mesmos termos e nomenclatura, aproxima a linguagem do desenvolvedor com a do 'analista de negocios'/clientes em geral.

O que o cliente entende: Usar um BO para alterar o VO e persistir usando o DAO no ORACLE ou "o cliente compra uma roupa"?

This message was edited 1 time. Last update was at 07/04/2010 15:22:28

Para mim o modelo anêmico é uma forma disfarçada de estruturar o sistema em módulos, igualzinho se fazia na programação procedural. O enfoque sai dos objetos e volta para os dados, ou "value objects".

Qual a diferença de um value object para um Struct? E de um BO para um módulo?

Virtual Machine Man Membro desde: 07/07/2008 13:10:41 Mensagens: 606 Offline

peczenyj, o sistema no qual me refiro é um sistema relativamente grande, com vários módulos e bem complexo.

Uma coisa que é bastante defendida é que o modelo anêmico dificulta a manutenção.
Mas a manutenção não fica mais fácil quando você já sabe onde está sendo processada a lógica, ou onde estão os dados?

Eu estou bem confuso quanto a essas coisas, não tenho uma opinião formada, do tipo: modelo anêmico é melhor ou modelo rico é melhor.

Não vejo a diferença na vantagem de utilizar um ou outro, e é por isso mesmo que eu abri o tópico, para ver se esclareço a idéia sobre isso afim de criar uma opinião.

GUJ Master Membro desde: 21/06/2007 23:27:21 Mensagens: 1850 Offline

Para mim, o modelo anemico é completamente válido..

Exemplo, suponhamos uma classe Endereco.

Nessa classe temos os atributos, rua, cep, bairro, etc.

A classe Endereco nada mais é do que um tipo de dados complexo. Ou seja, não tem que fazer nada mesmo, a nao ser, guardar as informacoes.

Virtual Machine Man Membro desde: 07/07/2008 13:10:41 Mensagens: 606 Offline

rogelgarcia wrote:Para mim, o modelo anemico é completamente válido..

Exemplo, suponhamos uma classe Endereco.

Nessa classe temos os atributos, rua, cep, bairro, etc.

A classe Endereco nada mais é do que um tipo de dados complexo. Ou seja, não tem que fazer nada mesmo, a nao ser, guardar as informacoes.

E as funcionalidades dessa entidade, aonde vão?

GUJ Master Membro desde: 21/06/2007 23:27:21 Mensagens: 1850 Offline

Voce fala funcionalidades para salvar e carregar os dados por exemplo?

Em um DAO

Virtual Machine Man Membro desde: 07/07/2008 13:10:41 Mensagens: 606 Offline

rogelgarcia wrote:Voce fala funcionalidades para salvar e carregar os dados por exemplo?

Em um DAO

Não, eu digo de funcionalidades de regra de negócio

This message was edited 1 time. Last update was at 07/04/2010 15:43:30

@rogelgarcia

No caso do Endereço, vc tem um EndereçoBO que valida o CEP? Vc tem um EndereçoBO.getInstance() ? Se tem então não é tão simples assim.

@Frango

Mas a manutenção não fica mais fácil quando você já sabe onde está sendo processada a lógica, ou onde estão os dados?

A manutenção fica mais facil se o que eu preciso saber esta diante de mim. Preciso abrir 2 (ou mais) arquivos para adicionar uma funcionalidade?

Veja este exemplo simples.

Imagine que agora PessoaFisica alem de sexo masculino e feminino tem "não informado" para ser mais politicamente correto. Alem de alterar a classe em si eu preciso alterar TODOS os pontos onde ela tem alguma Logica. Isso significa que eu preciso

1) Acreditar na documentação
2) Esperar que testes unitarios sejam uteis
3) Procurar com o eclipse (ou outra IDE) todos os lugares onde usam um objeto PessoaFisica
4) Rezar para não ter ninguem que use Reflection
5) Descobrir que um relatorio semestral deu pau na cara do gerente senior

Se tudo fica contido em uma classe, tem testes, esta bem feito, minimamente documentado, eu minimizo as dores de cabeça.

E, se a logica pode estar em 1 classe separada, ela pode estar em mais de uma classe. Isso quando vc não tem 2 ou mais classes que representem a mesma coisa sob pontos de vista diferentes mas em pacotes diferentes.

Edit: recentemente descobri que tinha um filtro em uma serie de requests que atualizavam outros sistemas. E atualizavam em um momento inadequado. Precisei fazer magia negra com grep, sed e awk para encontrar todos os 4 pontos em 3 projetos diferentes que faziam isso. Se o modelo fosse forte, eu poderia altualizar estes outros sistemas com algo do tipo Observer.

rogelgarcia wrote:Para mim, o modelo anemico é completamente válido..

Exemplo, suponhamos uma classe Endereco.

Nessa classe temos os atributos, rua, cep, bairro, etc.

A classe Endereco nada mais é do que um tipo de dados complexo. Ou seja, não tem que fazer nada mesmo, a nao ser, guardar as informacoes.

Por outro lado, como ficaria o BO da classe endereço? Seria praticamente vazio, no máximo fazendo delegação para o VO (ou uma cópia do VO, dependendo da estratégia que você use). Qualquer um desses três casos (classe final vazia, delegação pura e simples ou cópia de classe) é um sintoma de má modelagem.

Virtual Machine Man Membro desde: 07/07/2008 13:10:41 Mensagens: 606 Offline

peczenyj wrote:@rogelgarcia
@Frango

Mas a manutenção não fica mais fácil quando você já sabe onde está sendo processada a lógica, ou onde estão os dados?

A manutenção fica mais facil se o que eu preciso saber esta diante de mim. Preciso abrir 2 (ou mais) arquivos para adicionar uma funcionalidade?

Veja este exemplo simples.
ValidadorPessoaFisica vp = ValidadorPessoaFisica.getInstance(); if(vp.validaPessoaFisica(aluno)){ // salva no banco } else { // mostra erro }

Imagine que agora PessoaFisica alem de sexo masculino e feminino tem "não informado" para ser mais politicamente correto. Alem de alterar a classe em si eu preciso alterar TODOS os pontos onde ela tem alguma Logica. Isso significa que eu preciso

1) Acreditar na documentação
2) Esperar que testes unitarios sejam uteis
3) Procurar com o eclipse (ou outra IDE) todos os lugares onde usam um objeto PessoaFisica
4) Rezar para não ter ninguem que use Reflection
5) Descobrir que um relatorio semestral deu pau na cara do gerente senior

Se tudo fica contido em uma classe, tem testes, esta bem feito, minimamente documentado, eu minimizo as dores de cabeça.

E, se a logica pode estar em 1 classe separada, ela pode estar em mais de uma classe. Isso quando vc não tem 2 ou mais classes que representem a mesma coisa sob pontos de vista diferentes mas em pacotes diferentes.

Edit: recentemente descobri que tinha um filtro em uma serie de requests que atualizavam outros sistemas. E atualizavam em um momento inadequado. Precisei fazer magia negra com grep, sed e awk para encontrar todos os 4 pontos em 3 projetos diferentes que faziam isso. Se o modelo fosse forte, eu poderia altualizar estes outros sistemas com algo do tipo Observer.

Seguindo o seu exemplo,
Se fosse no modelo anêmico seria algo do tipo:

No modelo rico, eu teria uma classe que faz a lógica de validar pessoa física?
Não seria a mesma coisa que ter uma classe BO?

GUJ Master Membro desde: 21/06/2007 23:27:21 Mensagens: 1850 Offline

ViniGodoy wrote:

rogelgarcia wrote:Para mim, o modelo anemico é completamente válido..

Exemplo, suponhamos uma classe Endereco.

Nessa classe temos os atributos, rua, cep, bairro, etc.

A classe Endereco nada mais é do que um tipo de dados complexo. Ou seja, não tem que fazer nada mesmo, a nao ser, guardar as informacoes.

Por outro lado, como ficaria o BO da classe endereço? Seria praticamente vazio, no máximo fazendo delegação para o VO (ou uma cópia do VO, dependendo da estratégia que você use). Qualquer um desses três casos (classe final vazia, delegação pura e simples ou cópia de classe) é um sintoma de má modelagem.

VO seria o próprio Endereco
o BO teria métodos para manipulacao do Endereco, mas nao seria delegacao..

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