Digital
Innovación
Tecnología
26 de febrero de 2025
Design patterns en el desarrollo de software: ¿héroes o villanos?
La herramienta reduce la complejidad y permite la adaptabilidad del código, pero sus impactos deben ser analizados antes de la implementación

Se ha hablado mucho sobre el uso de los design patterns en el desarrollo de software y sus beneficios. Sin embargo, ¿la simple utilización de estos patrones garantiza realmente la solución de los problemas que pretenden resolver?
Los diseños patrones (o patrones de diseño) son soluciones estandarizadas para problemas recurrentes en el diseño de software, ofreciendo modelos para la resolución de los problemas, lo que hace que el código sea modular y legible.
Se espera que estos patrones se utilicen para facilitar el mantenimiento y optimizar la eficiencia del software, mejorar la calidad del código y facilitar la comunicación entre los integrantes del equipo de desarrollo. Además, como la herramienta reduce la complejidad y proporciona el reúso y la adaptabilidad del código, también posibilita ganancias de productividad para el equipo.
El historial de los patrones de diseño de software no es reciente. La idea surgió en la arquitectura antes de ser aplicada al desarrollo de software. En 1978, el arquitecto Christopher Alexander catalogó, junto con Sara Ishikawa y Murray Silverstein, 253 problemas comunes de arquitectura y sus soluciones en el libro “A Pattern Language: Towns, Buildings, Construction”.
Alexander definió que un patrón debería tener las siguientes características: encapsulamiento, generalidad, equilibrio, abstracción, apertura y combinatoria. Estas características acabaron influyendo en el desarrollo de los patrones de diseño de software. Más tarde, en 1987, Kent Beck y Ward Cunningham presentaron los primeros patrones en el área de la ciencia de la computación, para lenguajes orientados a objetos.
Sin embargo, solo en 1994, por influencia del trabajo de Alexander, ocurrió la popularización de los design patterns en el desarrollo de software. El lanzamiento del libro “Design Patterns: Elements of Reusable Object-Oriented Software”, de la “Gang of Four” (GoF) — Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides —, catalogando 23 patrones de diseño, formalizó el uso de la herramienta en el área.
Al utilizar patrones de diseño, es fundamental entender cada categoría para elegir el patrón más adecuado para el problema a resolver. Por ello, estos patrones se han dividido en tres categorías:
- Patrones creacionales: permiten crear objetos sin “atar” el código a clases específicas, que exigen el control del proceso de creación. Es como hacer un pedido de un sándwich en Subway: puedes elegir el pan, el relleno, el queso y la ensalada, pero permite que el dependiente monte tu bocadillo a su manera. Esto garantiza flexibilidad (puedes elegir diferentes tipos de queso y salsas), reutilización (los mismos ingredientes pueden ser utilizados para producir bocadillos diferentes) y independencia (nuevos ingredientes pueden ser añadidos, sin que necesites cambiar la forma de realizar tu pedido). Algunos ejemplos de patrones creacionales son Builder (clase que crea objetos para representar un informe con diferentes tipos de filtros, columnas y opciones de formato), Factory Method (una aplicación puede usar este patrón para cargar plugins o extensiones, donde cada plugin es instanciado por una factory específica) y Singleton (puede ser usado para la creación de un objeto que almacena las configuraciones de la aplicación, como información de conexión con la base de datos o preferencias del usuario);
- Patrones estructurales: se centran en la construcción de sistemas complejos a partir de partes más pequeñas (objetos y clases), que pueden encajar de diferentes maneras a través de una misma interfaz, resultando muy adecuados cuando se necesita garantizar una alta flexibilidad entre las partes. Funciona como piezas de Lego: aunque existen piezas de diferentes tamaños, colores y propósitos, el “patrón de encaje” es siempre el mismo, permitiendo que muchas cosas diferentes se construyan con las mismas piezas. Ejemplos: Adapter (cuando un sistema que usa una biblioteca de procesamiento de pagos con una interfaz específica necesita comunicarse con otra biblioteca de pagos con una interfaz diferente) y el patrón Facade (por ejemplo, durante el registro de un usuario en el sistema, la interfaz de registro interactúa con una clase, que coordina acciones necesarias en los subsistemas de validación, como persistencia en la Base de datos y envío de correo electrónico de confirmación);
- Patrones de comportamiento: tratan de la forma en que los objetos de un sistema trabajan juntos al realizar una tarea. Este patrón es útil cuando es necesario tener flexibilidad de comunicación y separación de responsabilidades dentro del sistema. Piense en una orquesta: cada músico (objeto) toca su instrumento siguiendo su propia partitura (su código) y es responsable de producir sonidos diferentes; su comportamiento está determinado por los comandos del director (aumentar volumen, cambiar el ritmo). Un ejemplo muy común es el patrón Observer (una plataforma de noticias puede usar este patrón para notificar a los suscriptores cuando se publica una nueva noticia); otro ejemplo es el patrón Command (en aplicaciones con interfaces gráficas, se usa para representar las acciones que pueden ser ejecutadas por los usuarios a través de menús y botones; cada elemento del menú o botón, como “Guardar”, “Abrir”, “Copiar” y “Pegar”, puede asociarse a un objeto Command específico, que encapsula la lógica necesaria para ejecutar la acción).
Algunos estudios han demostrado que los proyectos con equipos de desarrollo más grandes tienden a utilizar patrones de diseño con más frecuencia. Esto demuestra que los patrones se utilizan para mejorar la documentación y la comunicación entre los miembros del equipo. Además, los desarrolladores con más experiencia en programación y diseño son más propensos a utilizar patrones de diseño.
Al-Obeidallah (2021) analizó el impacto del patrón de diseño Adapter en la mantenibilidad del software — un atributo de calidad que indica cuán fácil es entender y modificar el software. Los autores crearon versiones de cuatro sistemas de software sin el patrón Adapter, utilizando técnicas de refactorización, y compararon métricas de software entre las versiones con y sin el patrón. El análisis de estas métricas, correlacionadas con la mantenibilidad en estudios anteriores, concluyó que el patrón Adapter impacta positivamente la mantenibilidad, reduciendo indicadores como el número de métodos y líneas de código y mejorando la cohesión.
Qasim (2021) investigó el impacto del uso de diferentes patrones de diseño en el consumo de energía de aplicaciones Android. Los autores implementaron cinco patrones (Singleton, Facade, Observer, Template y Abstract Factory) en dos aplicaciones open source, midiendo el consumo de energía antes y después de la implementación. Los resultados mostraron que patrones como Observer y Abstract Factory redujeron significativamente el consumo de energía, mientras que Singleton, en contrapartida, causó un aumento.
Sobreingeniería
Sin embargo, la simple utilización de un diseño pattern no garantiza las mejoras sugeridas. En general, las investigaciones sobre el impacto de design patterns en la calidad del software presentan resultados mixtos y contradictorios, sugiriendo que la relación entre design patterns y calidad del software es compleja e influenciada por varios factores. De hecho, existen estudios que señalan que algunos patrones pueden tener un impacto negativo en la calidad del software.
Paralelamente, algunos desarrolladores, especialmente los menos experimentados, pueden intentar aplicar design patterns en situaciones en las que soluciones más simples serían suficientes, un problema conocido como over-engineering.
También es posible que se produzca un impacto negativo en la productividad si algún patrón se usa mal, añadiendo complejidad excesiva y dificultando la comprensión, lo que puede hacer que las modificaciones en los códigos sean más difíciles. La implementación de patrones “directos al grano”, es decir, sin adaptarlos correctamente al contexto de la aplicación, puede generar soluciones ineficientes.
Existe una escasez de estudios empíricos que evalúen el impacto de los patrones de diseño en la calidad del software, y muchos estudios se basan en cuestionarios. De esta forma, es difícil analizar y adoptar un determinado patrón de diseño basándose en investigaciones y herramientas.
Cómo elegir
Entonces, ¿cómo elegir el diseño pattern más adecuado? Esta elección debe hacerse teniendo en cuenta diversos factores. En primer lugar, es necesario identificar exactamente cuál es el problema que se pretende resolver mediante un patrón. Los design patterns son soluciones para problemas recurrentes, por lo tanto, debemos verificar si la parte del software a estandarizar puede identificarse como un problema recurrente.
Solo después de este paso se debe analizar la intención de cada patrón, es decir, el tipo particular de problema que cada patrón puede resolver. También es necesario reflexionar sobre las consecuencias y trade-offs que el design pattern elegido traerá al desarrollo y al equipo. El patrón seleccionado debe facilitar la comunicación entre los miembros del equipo, y no dificultarla. Por ello, también es importante considerar la familiaridad que el equipo tiene con los patrones.
Como los patrones de diseño son soluciones listas para usar, puede ser que sea necesaria una adaptación al contexto del problema, a fin de obtener la mejor relación entre el costo de implementación y los beneficios que la solución traerá para el proyecto. Al fin y al cabo, los patrones de diseño fueron pensados para mejorar la calidad del código, de lo contrario, es mejor definir la propia implementación, de manera simplificada, buscando garantizar los mismos parámetros de calidad.
Con el fin de evaluar el impacto y la mejora de calidad del software, algunas métricas pueden ser calculadas antes y después de una refactorización para el uso de un determinado patrón de diseño. Algunos indicadores, como el Índice de Mantenibilidad, el Acoplamiento de Clases y Cohesión e incluso el Tiempo de Ejecución, pueden ser relevantes para evaluar los beneficios de la adopción del patrón de diseño en cuestión. Sin embargo, puede ser muy difícil obtener estas métricas para realizar esta evaluación más criteriosa.
Los patrones de diseño no son la “bala de plata” para todo tipo de problemas. Es importante analizar muy bien la situación antes de utilizarlos en algún proyecto de software, para verificar si traerán ventajas significativas. En primer lugar, se debe evaluar la real necesidad de adoptarlos en el proyecto.
A menudo, un buen punto de equilibrio puede ser desarrollar un código más simple, sin seguir un determinado patrón, y luego refactorizarlo para utilizar algún design pattern, evitando algunos problemas de implementación. Utilizando métricas y la percepción general del equipo, será posible evaluar si la utilización del patrón después de la refactorización mejoró la calidad del código y trajo beneficios para todos.
Independientemente de lo expuesto, es importante que todo desarrollador aprenda sobre patrones de diseño, para poder identificarlos y contribuir más fácilmente en diferentes proyectos de código abierto, por ejemplo. Aprender más sobre estos patrones expande los horizontes y permite que el desarrollador encuentre nuevas formas de resolver problemas y proponer mejoras en sistemas existentes, creando software con mucha más calidad.
| Para tener acceso a las referencias de este texto haga clic aquí. |
Este contenido fue producido por:

Lucas Schiolin Silveira
Formado en Ciencias de la Computación por la Unesp de Rio Claro, posee un MBA en Data Science y Analytics por la USP/ESALQ. Trabaja como desarrollador y líder técnico en Skylar. Es estudiante de IA, Machine Learning y Data Science.
Quién publicó esta columna
Skylar








