rogelgarcia wrote:Acho que tá havendo um mal entendido aqui..

No post do sergiotaborda é dito que os objetos fantoche.. como a classe Endereco que citei.. sao apenas isso fantoche.. e que isso é o correto.. porque a responsabilidade delas é apenas ser repositorio de dados

Aí os defensores do modelo rico.. dizem que as classes nao podem ser só fantoches.. que devemos evitar o modelo anemico...


E o sergiotaborda como outros são contra o modelo anemico...

O que voces chamam de modelo anemico???

Frango wrote:
O que o sergio defende é de que se o objeto não tem nenhuma funcionalidade (regra de negócio), você não precisa inserir alguma só para dizer que tem.

E se um objeto só tem o proposito de armazenar dados que assim seja, isso não torna o modelo anêmico.

Entendeu?

mochuara wrote:

Frango wrote:
O que o sergio defende é de que se o objeto não tem nenhuma funcionalidade (regra de negócio), você não precisa inserir alguma só para dizer que tem.

E se um objeto só tem o proposito de armazenar dados que assim seja, isso não torna o modelo anêmico.

Entendeu?

Independente de ser modelo anemico ou nao, se um objeto não tem funcionalidade (ou seja, não troca mensagens com outros objetos), qual motivo da sua existencia? Pra mim isso não é um bom sinal de design OO.

rogelgarcia wrote:

Alguns vão dizer que o anemic model é o que é exemplificado em 0, 1, 2, 3 ou 4...

Varia de acordo com a interpretação... o que eu considerava que seria anemic model ... seria o exemplo 0 ou 1...

No caso eu recomendaria fazer como no exemplo 1... Eu considero como anemic model (de acordo com o que eu já ouvi falar) .. mas não acho ruim... considero ser a melhor opção....

Vemos que o excesso de zelo para se evitar o anemic model, pode piorar o modelo, trazendo para ele responsabilidades que não são pertinentes...

Uma dúvida que tenho.. eh assim, no modelo 'rico', se eu quisesse re-utulizar meu domain model em outra aplicacao seria possivel? Pq tipo assim.. eu tenho um projeto que estou desenvolvendo a algum tempo onde eu separei o dominio em um jar separado... esse jar pertence exclusivamente a minha empresa... nela eu tenho os mais variados tipos de classes, desde pessoa até coisas especificas de outros projetos.. o que as diferencia é apenas o pacote... por exemplo... tenho com.teste.domain.Pessoa -> com.teste.model.PessoaFisica -> com.teste.cliente1.model.Cliente.. como seria isso no modelo rico??

Outra coisa... se eu quiser mudar a camada de persistencia no modelo 'rico', simplesmente alterando o jar app_hibernate para app_jdbc da minha aplicação é possível???

Outra... se eu quiser re-utilizar meu jar de domain e meu jar de persistence ou model em outra aplicação é possível???

rogelgarcia wrote:Considerando que há essa divergência entre os Anemic Models... eu acho que existem "níveis de anemia" e o que cada um considera anêmico varia nesses niveis..

(vou simplificar o código para ficar mais fácil entender... nao vou colocar os getters e setters tb nao)

Anemia 0 - Absolutamente nenhuma funcionalidade no Modelo...
class PessoaFisica { String nome; Date dataNascimento; } class PessoaFisicaBO { int getIdade(Pessoa p){...} boolean declarouIR(Pessoa p){ ... // web service para acessar o site da receita federal } } class PessoaFisicaDAO { void save(PessoaFisica p){...} } class PessoaFisicaAction { void processCrud(request) {...} }

Anemia 1 - Funcionalidades apenas pertinentes ao modelo (onde o modelo resolve por si só o problema)
class PessoaFisica { String nome; Date dataNascimento; int getIdade(){...} // MÉTODO NO MODELO } class PessoaFisicaBO { boolean declarouIR(Pessoa p){ ... // web service para acessar o site da receita federal } } class PessoaFisicaDAO { void save(PessoaFisica p){...} } class PessoaFisicaAction { void processCrud(request) {...} }


Anemia 2 - Funcionalidades apenas pertinentes ao modelo independente se precisa de outras informacoes, ou objetos...
class PessoaFisica { String nome; Date dataNascimento; int getIdade(){...} boolean declarouIR(){ // MÉTODO NO MODELO ... // web service para acessar o site da receita federal } } class PessoaFisicaBO { } class PessoaFisicaDAO { void save(PessoaFisica p){...} } class PessoaFisicaAction { void processCrud(request) {...} }


Anemia 3 - Funcionalidades pertinentes ao modelo mas independente de sua responsabilidade
class PessoaFisica { String nome; Date dataNascimento; int getIdade(){...} boolean declarouIR(){ ... // web service para acessar o site da receita federal } void save(){...}// MÉTODO NO MODELO } class PessoaFisicaBO { } class PessoaFisicaDAO { } class PessoaFisicaAction { void processCrud(request) {...} }


Anemia 4 - Funcionalidades pertinentes ao modelo mas independente de sua responsabilidade (nível extremo, igual ao do framework do carinha)
class PessoaFisica { String nome; Date dataNascimento; int getIdade(){...} boolean declarouIR(){ ... // web service para acessar o site da receita federal } void save(){...} void processCrud(request) {...}// MÉTODO NO MODELO } class PessoaFisicaBO { } class PessoaFisicaDAO { } class PessoaFisicaAction { }


Alguns vão dizer que o anemic model é o que é exemplificado em 0, 1, 2, 3 ou 4...

Varia de acordo com a interpretação... o que eu considerava que seria anemic model ... seria o exemplo 0 ou 1...

No caso eu recomendaria fazer como no exemplo 1... Eu considero como anemic model (de acordo com o que eu já ouvi falar) .. mas não acho ruim... considero ser a melhor opção....

Vemos que o excesso de zelo para se evitar o anemic model, pode piorar o modelo, trazendo para ele responsabilidades que não são pertinentes...

rogelgarcia wrote:É.. dá pra ver que vc tá nervoso mesmo.. heheheheh

rogelgarcia wrote:Eu ia colocar um com vitamina B12 pra ver se melhorava.. ehhehe