Sem falar em Aspectos. A discussão não tem fim, porém qualquer forma de programar mais OO e menos Procedural é interessante pois da base para as proximas ações.
Sim, continua a mesma coisa que no modelo anêmico. A regra de negócios sabe chamar a persistência, e a persistência sabe como extrair os dados deste objeto para gravar em algum lugar.
Na verdade mais se resume a falar “Me persista”, e um gerenciador se vira para fazer isto.
Cara, o que vc tá falando? Que eu não sei orientação a objetos??
“Básico do Básico”
Cara… para que possamos ter uma livre discussão, te convido a apresentar a todos os membros do GUJ o básico do básico em orientação a objetos, e ainda… Me convença com embasamento teórico de que usar o seu modelo é melhor que usar o meu!
É muito conveniente criar domains enxutos, que simplesmente transitam entre o banco e a tela. Isso porque ORMs como o hibernate recomendam DAO, e nada mais natural do que o DAO implementar os comportamentos que eram pra estar nesses objetos, consequentemente sem inteligencia imbutida.
O que é feio mesmo é criar várias camadas de beans burrões com esses.
Pra quem acha que isso é totalmente errado, só olhar os exemplos do Hibernate pra discutir lá com o Gavin King :twisted:
Basicamente, seguimos 3 regras (definidas no GOF) para boas práticas de OO:
1 - Favorecer composição ao invés de herança
2 - Programar para interfaces e não para implementações
3 - Alta coesão e baixo acoplamento
Num modelo rico, onde o objeto sabe como se salva e como se carrega, você terá código de persistencia dentro dele (o active record do rails eu considero mais válido pois, voce nao codifica isso na classe, o framework é que implementa pra voce)
Se voce tem que validar o objeto, provavelmente vc fará algo do tipo ValidatorUtils.validateEmail(pessoa.getEmail())
Isso vai ferir o item 3 das boas práticas de programação. Muitas lógicas misturadas na mesma classe, causando baixa coesão.
Se voce pensar na interface de PessoaFisica, o que é uma pessoa física? O que ela tem? O que ela pode fazer? Faz parte da pessoa física se salvar? Você se salva? Se carrega?
Se voce faz um programa chamando pessoaFisica.save(), voce começa a programar para a implementação, pois a interface que define uma pessoa física, não tem isso de salvar…
Ferindo o principio 2.
É mais ou menos como se um bolo fosse representado pela classe Bolo e nessa classe tivesse um método chamado assar. Quando voce compra um bolo, tem um botão que ele se assa sozinho? Não, voce precisa de um forno…
Só o fato de diminuirmos o Ruído Semântico da camada de negócios com um modelo mais rico dá frutos sensacionais.
Mas eu acho válido por exemplo um método getIdade() na pessoa física…
[quote=peczenyj]Humm… isto pode te dar uma luz
http://blog.caelum.com.br/2007/06/09/repository-seu-modelo-mais-orientado-a-objeto/[/quote]
Valeu pelo link.
Eu ainda sou meio leigo nesse conceito de repositórios.
Utilizo somente DAOs.
Para programar OO eu necessariamente preciso utilizar repositórios?
Tem algum link legal sobre repositórios?
Valeu
http://blog.fragmental.com.br/2007/03/01/voce-pergunta-001-daos-e-repositorios/
http://blog.fragmental.com.br/2008/05/22/domain-driven-design-e-simples/
http://blog.fragmental.com.br/2010/01/18/domain-driven-bolovo-passando-conhecimento-e-etc/
http://www.guj.com.br/posts/list/134767.java
faz uma busca por repositórios aqui no guj, vão vir milhões de links. kkkkk
[quote=Frango]
Então seria apenas uma questão de preferência em separar a entidade da lógica. É por isso a pergunta do título do tópico: Modelo Anêmico é realmente ruim? Ele realmente influencia negativamente?[/quote]
Sim. Leia a matéria da javamagazine deste mes sobre coesão e acoplamento. O problema do modelo anémico é falta de coesão e excesso de acoplamento.
Não se trata de colocar todas as funções numa classe só, trata-se de separar corretamente o que é de cada classe. Isso é SoC, e quando mal feito leva a problemas de coesão e acoplamento
Repositório é somente uma abstração de onde guardar e obter objetos, normalmente os DAOs são as classes concretas que implementam os repositórios.
Mas se for começar a pesquisar sobre isto, leia primeiro o livro do Eric Evans, Domain Driven Design. Ele que dá a base de tudo.
[quote=sergiotaborda]
Sim. Leia a matéria da javamagazine deste mes sobre coesão e acoplamento. O problema do modelo anémico é falta de coesão e excesso de acoplamento.
Não se trata de colocar todas as funções numa classe só, trata-se de separar corretamente o que é de cada classe. Isso é SoC, e quando mal feito leva a problemas de coesão e acoplamento[/quote]
Eu já acho o contrario… como postei anteriormente…
Mas vou dar uma lida nessa revista… qual é o número?
[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]
Essa não é a definição de modelo anêmico. Modelo anemico é quando, havendo algum comportamento, ele é colocado em um objeto diferente daquele que possui os dados. O que vai contra aos principios da OO que é agrupar os dois no mesmo objeto.
[quote=rogelgarcia][quote=sergiotaborda]
Sim. Leia a matéria da javamagazine deste mes sobre coesão e acoplamento. O problema do modelo anémico é falta de coesão e excesso de acoplamento.
Não se trata de colocar todas as funções numa classe só, trata-se de separar corretamente o que é de cada classe. Isso é SoC, e quando mal feito leva a problemas de coesão e acoplamento[/quote]
Eu já acho o contrario… como postei anteriormente…
Mas vou dar uma lida nessa revista… qual é o número?[/quote]
Se não me engano é a 77.
Existe uma diferença entre o método getIdade(Date) em pessoa e o método save() em pessoa. ActiveRecord é anémico.
É da responsabilidade da pessoa saber a sua idade, mas não é responsabilidade da pessoa ter codigo de “save” que é um conceito de TI que nada tem que ver com pessoas.
Eu comentei sobre modelo anêmico faz algum tempo no meu blog antigo.
[quote=mochuara][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]
Essa não é a definição de modelo anêmico. Modelo anemico é quando, havendo algum comportamento, ele é colocado em um objeto diferente daquele que possui os dados. O que vai contra aos principios da OO que é agrupar os dois no mesmo objeto.[/quote]
Faço das suas as minhas palavras.
Aliás, acho que colocar o validaCep() em uma outra classe é errado… Não errado, mas eu não gostaria de fazer dessa maneira. É a mesma coisa que colocar calcularIdade() de um objeto do tipo Pessoa dentro de uma outra classe… Vira aquela coisa de gets e sets pra tudo quanto é lado (lembrem-se dos artigos de que getters e setters ‘are evil’). Mas isso é só a opinião de um gordo que nem sabe digitar direito né 
Ah, lembrei de uma coisa. Eu estava lendo um artigo sobre um framework que tinha saído na época (final de 2008, começo de 2009, alguma coisa assim). Lá, até mesmo os CRUDs estavam sendo codificados em classes Pessoas, Clientes e afins. O que vocês acham disso? Acaba com toda aquela coisa de DAO e Repository, o que as vezes não é legal.
[quote=mochuara][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]
Essa não é a definição de modelo anêmico. Modelo anemico é quando, havendo algum comportamento, ele é colocado em um objeto diferente daquele que possui os dados. O que vai contra aos principios da OO que é agrupar os dois no mesmo objeto.[/quote]
Eu considerei que havia o comportamento de salvar por exemplo … que nao deve ser colocado na classe
[quote=rogelgarcia][quote=mochuara][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]
Essa não é a definição de modelo anêmico. Modelo anemico é quando, havendo algum comportamento, ele é colocado em um objeto diferente daquele que possui os dados. O que vai contra aos principios da OO que é agrupar os dois no mesmo objeto.[/quote]
Eu considerei que havia o comportamento de salvar por exemplo … que nao deve ser colocado na classe[/quote]
Continua não tendo nada a ver com modelo anêmico. O modelo é anêmico quando, deliberadamente ou por força de uma arquitetura pré-definida, se resolve separar aquilo que outrora deveria estar agrupado em unico objeto.
[quote=sergiotaborda][quote=Frango]
Então seria apenas uma questão de preferência em separar a entidade da lógica. É por isso a pergunta do título do tópico: Modelo Anêmico é realmente ruim? Ele realmente influencia negativamente?[/quote]
Sim. Leia a matéria da javamagazine deste mes sobre coesão e acoplamento. O problema do modelo anémico é falta de coesão e excesso de acoplamento.
Não se trata de colocar todas as funções numa classe só, trata-se de separar corretamente o que é de cada classe. Isso é SoC, e quando mal feito leva a problemas de coesão e acoplamento[/quote]
Confesso que desde o começo da Thread esperava uma resposta sua. hahaha
Li o seu post e estou começando a entender melhor e a acreditar que o modelo rico é melhor por diminuir o acoplamento e aumentar a coesão.
Mas uma dúvida que ainda tenho, como fica a persistência desses objetos? Eu posso ter um DAO como propriedade da entidade ou eu tenho que instanciar o DAO dentro dos meus métodos apenas quando eu precisar usa-los?
abraços
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 um conjunto 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???
[quote=mochuara][quote=rogelgarcia][quote=mochuara][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]
Essa não é a definição de modelo anêmico. Modelo anemico é quando, havendo algum comportamento, ele é colocado em um objeto diferente daquele que possui os dados. O que vai contra aos principios da OO que é agrupar os dois no mesmo objeto.[/quote]
Eu considerei que havia o comportamento de salvar por exemplo … que nao deve ser colocado na classe[/quote]
Continua não tendo nada a ver com modelo anêmico. O modelo é anêmico quando, deliberadamente ou por força de uma arquitetura pré-definida, se resolve separar aquilo que outrora deveria estar agrupado em unico objeto.[/quote]
Pois entao… tem gente que entende que o salvar deve estar no VO … se eu digo que o salvar nao deve ficar no VO… esses que consideram o contrario… chamam o meu modelo de anemico