O que é Modelo Anêmico? E por que fugir dele?
4 minutos de leitura
Autor(a)
maniche
Inscreva-se em nossa Newsletter
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
4 minutos de leitura
Autor(a)
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Pensar em design e arquitetura é sem dúvida o grande desafio de um desenvolvedor mais experiente. Todos nós já trabalhamos com linguagens orientadas a objetos há algum tempo, e já tivemos tempo suficiente para perceber que, quando a interação entre as classes do sistema não é clara o suficiente, temos diversos problemas: repetição de código, dificuldade de manutenção, propagação de bugs, e etc.
Por esse motivo, é que tanto ouvimos falar sobre diferentes tipos de arquitetura. E com certeza, o termo mais popular sobre isso é a tal da arquitetura em camadas. Quem nunca viu o sistema dividido em 3 camadas diferentes, a camada de modelo, a camada de regras de negócio, e a camada de acesso a dados?
A ideia dessa arquitetura é justamente separar as regras de negócio em um canto, do conjunto dos atributos da entidade em outro, do acesso aos dados. E, com isso, facilitar a manutenção. O código abaixo é um exemplo dessa separação:
// camada de modelo class NotaFiscal { private int numero; private double valor; private String razaoSocial; // getters e setters }
// camada de regra de negocios class NotaFiscalBLL { public void encerraNota(NotaFiscal nf) { nf.setEncerrada(true); } }
// camada de acesso a dados class NotaFiscalDAO { public void insere(NotaFiscal nf) { // insert into nota fiscal (...) } }
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.
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.
Avalie este artigo
