Siempre uno quiere mejorar sus clases para que nuestro código sea mejor y mejoremos profesionalmente. Mi idea es escribir varios artículos con mejoras de código que yo fui viendo a lo largo de los años para que quizás alguno encuentre algún punto de mejora que le interese.
En esta entrada voy a comentar un poco sobre la encapsulación y cómo uno puede estar generando clases con demasiadas responsabilidades y dominios anémicos.
Encapsulación
La encapsulación es uno de los conceptos fundamentales de la programación orientada a objetos. La idea de la encapsulación es mantener en el objeto su lógica y comportamiento, así como sus propiedades. De esta forma, nos ayuda aislando detalles de implementación del comportamiento expuesto a los clientes.
Si bien es uno de los pilares de OOP es muy frecuente no cumplirla del todo. Pasemos a un ejemplo con una clase Character, a la que en este caso le quiero modificar la vida.
Es un camino perfectamente viable. El problema es que estoy rompiendo esta encapsulación de la que hablamos.
¿Qué conlleva romper la encapsulación?
Bueno, son varios los motivos pero voy a destacar algunos de los que yo me encontré.
- Mala organización y duplicación de código
- Acoplamiento
- Dominio anémico
Mala organización y duplicación de código
Acoplamiento
¿Por qué dejamos que cualquier clase que cure maneje la lógica de cómo se cura el personaje? Estamos teniendo más una responsabilidad en esas clases. Esto significa que si yo vengo y cambio cómo funciona la vida va a explotar el código por todos lados. Si separo la vida en dos variables, una con la vida máxima que podría tener y otra con la vida actual, por ejemplo, ya me va a empezar a fallar por todos lados menos en la propia clase que tiene esas variables.
Otro ejemplo podría ser que si tiene menos de 30% de vida cure el doble. De la manera que tenemos organizada el código esto sería una verdadera molestia y terminaríamos teniendo un mismo código duplicado de lógica por todas las clases en vez de converger en un sólo lugar.
En resumen, estoy acoplando el código a cómo se cura, cuando en realidad lo único que le importa es que se cure. El resto de las clases no debería saber cómo se hace.
Dominio anémico
Cuando mencionamos el dominio anémico nos referimos a objetos que tienen muy poca lógica y maneja más que nada datos. Es un anti-patrón que va contra lo que plantea la programación orientada a objetos.
Revisando códigos antiguos, de cuando empezaba a programar, veo que es muy frecuente caer en este problema. Deberíamos de tratar de de siempre tener objetos de dominio con comportamiento, donde sus variables sólo son usadas por la propia clase y el resto interactúa con el objeto mediante los comportamientos que les habilita. De esta forma, la lógica queda en un solo lugar, el resto de clases delegan la responsabilidad del comportamiento al objeto, me queda un dominio mucho más enriquecido, y sobretodo no rompo el encapsulamiento.
Poniendo en común
Entonces, siguiendo los puntos que hablamos, podría refactorear nuestro código agregando un comportamiento a nuestra clase para curarse y que ahí maneje todo lo relacionado a eso. Nos quedaría algo así:
