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

O texto diz que a separação entre modelo, regras de negócio e acesso a dados pode levar a um modo de programar procedural dentro de uma arquitetura orientada a objetos. Isso gera classes grandes, regras repetidas e código difícil de manter e evoluir.

Fichamento

#

• A interação pouco clara entre classes traz repetição de código, dificuldade de manutenção e propagação de bugs.
• A arquitetura em camadas separa regras de negócio, atributos da entidade e acesso a dados.
• O texto afirma que, na prática, essa separação costuma produzir programação procedural.
• Nesse cenário, as regras de negócio ficam espalhadas e repetidas em muitas classes.
• Esse arranjo é chamado de modelo anêmico.
• O autor cita críticas de Paulo Silveira, Martin Fowler e Philip Calçado ao mesmo problema.
• O texto diz que essa prática joga fora benefícios da orientação a objetos como reutilização de código, polimorfismo e herança.
• Entre os motivos apontados para isso estão a dificuldade de usar bem os recursos da OO, exemplos de “boas práticas” que sugeriam arquiteturas parecidas e a falsa sensação de facilidade de manutenção.
• A recomendação final é evitar modelos anêmicos e preferir objetos ricos, com atributos e métodos que manipulem esses atributos.
• O texto também recomenda usar abstrações, polimorfismo, herança e encapsulamento quando houver necessidade de flexibilidade.