O que é Modelo Anêmico? E por que fugir dele?

O problema é que, na prática, acontece exatamente o contrário! Veja, no momento que separamos dados de um lado, e comportamento de outro, voltamos a programar de maneira procedural. Nesse tipo de arquitetura, é comum vermos imensas classes com as regras de negócios repetidas e espalhadas. A consequência disso? Um código dificílimo de ser mantido e evoluído. Tanto é que, hoje, esse tipo de arquitetura, é conhecida por modelo anêmico.

Muita gente já falou sobre isso: o Paulo Silveira comentou dos problemas da criação de getters e setters sem qualquer cuidado, o Martin Fowler tem um texto só sobre modelos anêmicos no seu site, e o Philip Calçado também já brigou bastante com os BOs e VOs (nomes que as pessoas do mundo Java dão aos objetos que guardam as regras de negócio e aos que guardam os dados de uma entidade). É, com certeza, um assunto bem popular na comunidade.

Estamos jogando fora todos os benefícios que a orientação a objetos nos dá! Não preciso defender aqui as vantagens da OO: reutilização de código, polimorfismo, herança, etc.

Mas se os problemas são claros, por quê as pessoas fazem assim? Por vários motivos diferentes.

• É mais fácil programar de maneira procedural do que de maneira orientada a objetos. Afinal, fazer bom uso de polimorfismo, herança, encapsulamento e abstrações, não é fácil.
• Tanto a Sun quanto a Microsoft já divulgaram "catálogo de boas práticas", onde a arquitetura sugerida era parecida com essa. A diferença é que em ambos os textos, a ideia era discutir arquitetura para sistemas distribuídos. Mesmo nesse caso, esse tipo de arquitetura não é a melhor, mas essa discussão fica para um próximo post.
• Por que, por algum motivo estranho, ter essas camadas dá uma falsa sensação de facilidade de manutenção, afinal "tudo está bem isolado".

Fuja de modelos anêmicos. Tenha objetos ricos, isto é, objetos que tenham atributos, e métodos que manipulam esses atributos. Faça uso de abstrações, polimorfismo e herança nos momentos que precisar de flexibilidade. Encapsule tudo para que as mudanças sejam facilmente propagáveis e não haja código espalhado.

Como fazer isso? Orientação a objetos... Não há mágica. Onde aprender? Nos diversos cursos que temos qualidade de código no Alura, como Orientação a Objetos, refatoração de código, e TDD.