Modelo Anêmico é realmente ruim?

Assuntos Gerais
#1

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

#2

[quote=Frango]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[/quote]

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.

#3

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.

#4

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.

#5

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”?

#6

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?

#7

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.

#8

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.

#9

[quote=rogelgarcia]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.

[/quote]

E as funcionalidades dessa entidade, aonde vão?

#10

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

Em um DAO

#11

[quote=rogelgarcia]Voce fala funcionalidades para salvar e carregar os dados por exemplo?

Em um DAO[/quote]

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

#12

@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

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.

#13

[quote=rogelgarcia]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.

[/quote]

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.

#14

[quote=peczenyj]@rogelgarcia
@Frango

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.[/quote]

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

PessoaFisicaBO bo = new PessoaFisicaBO();
if(bo.validaPessoaFisica(pessoa)) {
//salva
}
else {
//erro
}

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?

#15

[quote=ViniGodoy][quote=rogelgarcia]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.

[/quote]

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.[/quote]

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

#16

Não, vc não teria. A própia pessoa fisica faria isso.

#17

A validacao eu nao costumo colocar nem no VO nem no BO… uso uma arquitetura separada de validacao… que valida os objetos onde seja necessário…

Mas o VO (Endereco) continua anemico nesse caso…

eu nao tenho um método

endereco.isValid()
#18

Vamos pegar o PessoaFisica por exemplo… num modelo Rico… como ficariam as funcionalidades para salvar e carregar os dados?

#19

[quote=rogelgarcia][quote=ViniGodoy][quote=rogelgarcia]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.

[/quote]

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.[/quote]

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

[/quote]

Uma entidade deve conter apenas as coisas que a compoem… qualquer validação ou algo do genero deve ser feita em classe específica, pode ser uma BO. O design pattern BO acessa as daos ou outros metodos da BO ou ainda outra camada da aplicação que esteja em, digamos… “uma camada a frente”, porém jamais retornando… a ideia eh simples

View -> Controller -> Facade/BO -> BO -> DAO -> VO

qualquer coisa do genero

VO -> DAO
DAO -> BO
VO -> BO
Facade -> Controller
DAO -> Facade

não pode ocorrer

uma camada só pode chamar sua camada subsequente

#20

onde fica a persistencia?

Depende do padrão que vc adotar. Vc pode usar activeRecord e o objeto sabe se salvar (e como recuperar) como é comum em Rails. Ou pode usar Repositorios (DDD). O lance é que persistência tem pouco haver com negocio e sim com uma particularidade do seu sistema: eu preciso usar um banco de dados ou outra coisa pois os objetos não podem ficar em memoria (que é um recurso finito) pra sempre.

@dohko

Um objeto não deveria ser capaz de criticar e validar o seu estado interno? Pq eu preciso de uma classe externa?

Não seria mais Simples ter Objetos que se relacionam como Objetos?