Sobre el modelo anémico y la POO
Ayer, unas horas después de leer el post de @kinisoftware, Modelos de dominio anémicos, POJOs y demás seres del lugar, me encontré una discusión en twitter a varias bandas(sitio que no es ni mucho menos el mejor para debates así... sigo echando de menos las conversaciones/discusiones que teníamos entre una micro-comunidad en jaiku, pero ese es otro tema) sobre el anti-patrón del modelo anémico.
Hablando del tema vi tuits de @kinisoftware, @albertovilches, @jmbeas, @genezeta, @jneira, @jlhuertas... y fijo que me pierdo a algunos más de gente que no sigo. Como es habitual, yo no me mojé demasiado :P. Por un lado soy un chaquetero, y por otro esta gente sabe mucho y me pueden dejar a la altura del betún en cualquier momento :D
Por resumir un poco esto del modelo anémico, viene a ser que el modelo está implementado con DTOs, cuya única responsabilidad es encapsular datos para transferirlos a otra parte(ej: de una base de datos a la vista de una app). Cosa que creo aún es bastante habitual en muchas aplicaciones que utilizan ORMs o similares(llámense Hibernate, ActiveRecord, GORM, Doctrine, MyBatis... o soluciones home-made)... Pues resulta que eso es un anti-patrón, más que nada porque por hacer eso probablemente estemos rompiendo el paradigma de programación orientada a objetos.
Recuerdo cuando me enseñaban POO(con Java) que una clase Rectangulo tenía un atributo base y otro altura con sus getters y setters y un método calculaArea() que devolvía su área(vale, y probablemente extendería de Poligono :P). Vamos, que se supone que un objeto combina estado y comportamiento, por eso veo por ejemplo hablando una clase de dominio Noticia que tiene un atributo propietario puede tener un método del estilo:
public boolean esPropiedadDe(Usuario usuario){
return propietario.equals(usuario)
}
La cosa es que en los frameworks MVC ese tipo de lógica la he visto(y sí, también la he puesto! XD) en la capa del controlador, cuando se supone que es una capa que debe ser lo más tonta posible en cuanto a lógica de negocio (o ya puestos, tonta del todo :D, skinny controller-fat model), y con la moda de las capas de servicio con los Spring & co(Grails como una de esas víctimas colaterales) ha resultado que esa lógica se pone en la capa de servicio para evitar ponerla en el controlador y seguir dejando a las clases de dominio como DTOs(o modelos anémicos).
¿Eso quiere decir que siempre pongo la lógica en las clases de dominio?
No, pero procuro hacerlo siempre que puedo identificar responsabilidades en una clase del dominio. Aún así, en ocasiones me encuentro con lógica que pasa a alguna clase en la capa de servicio, principalmente porque no consigo identificar qué clase debería ser la responsable, afecte a varias clases de dominio o simplemente sean comportamientos que no tienen que ver con la lógica de negocio pura y dura. Por supuesto teniendo en cuenta que esas decisiones sean cosa mía :D
De todas formas, ya se sabe que en esto del desarrollo de software todo depende de muchos factores(principalmente de los gustos y costumbres de los desarrolladores) y nadie tiene LA respuesta. Eso es lo que hace más interesante el mundillo, ¿o no? :D
PD: Disculpad que os tengáis que imaginar parte del código y el spanglish rarillo en los ejemplos, el código de verdad hace tiempo que procuro escribirlo siempre en inglés :P
