Ya hemos analizado múltiples patrones en post anteriores. Hemos revisado las buenas prácticas y principios de desarrollo orientado a objetos. Sin embargo, también existe un lado oscuro del diseño de software, ciertas prácticas a las que llamamos antipatrones.
Los patrones de diseño se definen como, soluciones generales a problemas recurrentes en un contexto particular. ¿Cómo podemos definir los antipatrones?
Según el libro Head First Design Patterns, un antipatron nos indica como ir de un problema a una mala solución.
En otras palabras, la mayoría de las veces, son soluciones rápidas a un problema que no hemos analizado correctamente.
Al igual que los patrones, los antipatrones se documentan con el fin de asegurarse que ninguna persona que tenga un problema similar, piense en utilizar la solución propuesta en el antipatrón.
A continuación revisamos los elementos de un antipatrón:
- ¿Por qué la solución es atractiva/necesaria?
- ¿Por qué la solución no es la mejor a largo plazo?
- ¿Qué patrones de diseño pueden ser aplicados que pueden solucionar el problema?
Al documentar un antipatrón nos interesa obtener la siguiente información, según Head First Design Patterns.
- Nombre: Una forma de identificar el antipatrón y poder hacer referencia a él.
- Problema: Descripción de la situación/problema actual.
- Contexto: En qué escenario se está dando la situación o problema.
- Razones: Por qué resulta atractivo el antipatrón, es decir, la justificación de la implementación o uso del antipatrón.
- Supuesta Solución: Descripción de la solución deficiente.
- Solución Real: Descripción del proceso correcto para solucionar el problema.
- Ejemplos: Ejemplos de otros proyectos o compañías que implementaron el antipatrón y no dio los resultados esperados.
En el libro Head First Design Patterns, nos dan un ejemplo de un antipatrón.
- Nombre: Martillo de Oro.
- Problema: Es necesario escoger tecnologías para el equipo de desarrollo y se cree que debe existir una sola tecnología para toda la arquitectura.
- Contexto: Es necesario crear un nuevo módulo a un sistema actual que no utiliza la tecnología definida en la arquitectura.
- Razones:
- El equipo de desarrollo solo conoce esa tecnología.
- El equipo se siente cómodo con la tecnología actual.
- Nuevas tecnologías parecen ser muy riesgosas.
- Es más fácil estimar tareas si se utiliza la tecnología actual.
- Supuesta Solución: Usar la tecnología actual, ya que el equipo la ha aplicado en múltiples ocasiones y es el estándar de la compañía.
- Solución Real: Extender el conocimiento del equipo para adoptar nuevas tecnologías que permitan el crecimiento profesional del equipo en general.
- Ejemplos: Compañías que utilizan sus propias versiones de manejo de mensajes cuando existen soluciones como ApacheMQ que ya se encargan de ese tipo de procesos.
El ejemplo anterior muestra claramente los detalles del antipatrón y nos asegura que cualquier persona de la compañía pueda entenderlo y evitarlo en los diseños de las aplicaciones.
Existen infinidad de antipatrones, nuestro deber como profesionales de software es identificarlos, documentarlos y sobretodo evitarlos en nuestros diseños.
Recordá suscribirte aquí para recibir las últimas actualizaciones todas las semanas.
Referencias:
Libro Head First Design Patterns. Versión digital.