Escrito por: Jorge Gutiérrez, 30 de mayo 2022

Los patrones de diseño son soluciones generales de modelado a problemas comunes que se enfrenta un desarrollador al momento de diseñar una solución de sofware [1]. En otras palabras, un patrón de diseño es una plantilla que se puede aplicar cuando se identifican ciertas características en el problema a resolver. Por ejemplo, al diseñar una plataforma de streaming como Disney+ se tiene el reto de la creación, modificación y eliminación de opciones de entretenimiento. Por otro lado, en una app de delivery como Uber Eats, se tiene la creación, modificación y eliminación de ofertas de comida. ¿Sera el mismo problema en ambos casos?, ¿podrían solucionarse ambos problemas con la misma estructura?, la respuesta es sí, al abstraer el problema general, eliminando los detalles propios de la lógica de negocio de ambos casos, el problema a resolver es el manejo de productos. Problema que sin duda alguna resolvió la persona que diseño el sistema de McDonald hace décadas, y que también han resuelto miles de desarrolladores en todos estos años.
Aunque el termino patrones de diseño se comenzó a utilizar en la década de los 90’s, desde los años 80’s ya se comenzaba a hablar de la reutilización y refactorización del software [2]. El termino fue utilizado por primera vez en el año de 1994 con la publicación del libro “Patrones de diseño: elementos de software orientado a objetos reutilizables” por parte de los autores; Erich Gamma, Ralph Johnson, Richard Helm y John Vlissides [3]. Todos ellos conocidos como la banda de cuatro con el pasar de los años por la comunidad de desarrolladores. En su publicación, ellos hicieron una recopilación de los problemas más comunes de diseño de software a los que se habían enfrentado los desarrolladores hasta ese momento, y de toda esa experiencia de solucionar los mismos problemas una y otra vez, propusieron 23 patrones de diseño para solucionarlos. A dichos patrones de diseño se les conoce hoy en día como clásicos, y con el transcurrir de los años se han ido agregando otros [4].
Los patrones de diseño se clasifican en 3 grandes grupos dependiendo la naturaleza del problema a resolver. Están los patrones de diseño creacionales, los cuales se encargan como su nombre lo dice de la creación de nuevas clases y la instanciación de nuevos objetos [3], permiten solucionar el problema de tener un proceso de creación de clases y objetos reutilizable, es decir, que se pueda utilizar para las nuevas clases y objetos que surjan cuando se extienda la funcionalidad del software, y tener un proceso flexible, que se puedan realizar cambios fácilmente sin afectar otras funcionalidades. Por ejemplo, en esta clasificación se encuentra el patrón “Abstract Factory”, que permite crear familias enteras de objetos relacionados, el patrón “Builder”, que permite construir objetos que tienen una gran cantidad de configuraciones posibles reutilizando el mismo código de construcción.
También están los patrones de diseño estructurales, los cuales se encargan de conectar o combinar objetos de distintas clases entre sí para generar nuevas clases con estructuras más grandes y complejas [3]. Permiten solucionar el problema de mejorar la legibilidad y facilitar el mantenimiento del código, esa facilidad de mantenimiento permite agregar nuevas funcionalidades a las clases involucradas sin tener que realizar grandes cambios en la estructura de las mismas. Por ejemplo, está el patrón “Decorator, que permite agregar nuevas funcionalidades a objetos sin tener que cambiar la estructura interna de los mismos.
Y por último están los patrones de diseño de comportamiento, es la clasificación con la mayor cantidad de patrones, estos se caracterizan por tener un nivel de abstracción menor al de los anteriores, tienen por objetivo resolver problemas específicos mediante la comunicación efectiva entre objetos y la asignación de responsabilidad a los mismos [3]. Por ejemplo, está el patrón “State” el cual es una implementación del concepto de máquina de estado, permite modificar el comportamiento de un objeto dependiendo el estado interno del mismo objeto.
Durante más de dos décadas los patrones de diseño han demostrado los beneficios de su implementación en la industria del software. A pesar que el área de la ciencia de datos no maneja soluciones de software tan grandes y complejas como la industria tradicional, esta puede verse beneficiada también de la implementación de los mismos.
En las etapas de análisis, exploración de datos, construcción del modelo y evaluación del mismo lo más importante para el científico de datos es obtener resultados, comprender la información, y obtener un modelo con buenas métricas lo más pronto posible, si bien no importa la forma o estructura del código que se utilice, al ser una tarea repetitiva eventualmente se podrá realizar alguna refactorización y reutilización de código empleando patrones de diseño.
Es en la etapa de puesta a producción donde más provecho se puede obtener de la implementación de patrones de diseño. Por ejemplo, puede reducir el tiempo que le toma al científico de datos codificar las clases que se utilizaran para formalizar la puesta en producción de un modelo, al ser soluciones que se han utilizado miles de veces reduce el tiempo de verificación de la lógica del código. También permite manejar un lenguaje en común, lo cual facilitara la explicación del código a otros miembros del equipo de ciencia de datos. De igual modo, muchas veces en la etapa de implementación en producción se tiene interacción con otros equipos de la compañía, como las áreas de desarrollo, soporte, arquitectura, etc. Al manejar un cierto tipo de estándar puede mejorar la comunicación entre equipos de distintas áreas.
Los patrones de diseño no deben tomarse como una verdad absoluta, como toda metodología tienen sus detractores [5], no todo código que se desarrolla debe implementar por fuerza más de algún patrón, sino que su implementación depende en gran medida del problema que se quiera resolver. Como el volumen de código que desarrolla un científico de datos es menor al de un desarrollador de software, por lo que es posible que haya patrones que el científico de datos nunca tenga la necesidad de implementar. Identificar cuando implementar un patrón o no es parte del proceso de aprendizaje del científico de datos.
[1] Feathers, Michael C. Ottinger, Timonthy R. Langr, Jeffrey J. Schuchert, Brett L. Grenning, James W. Wampler Kevin D. (2008). Clean Code: A handbook of agile software craftsmanship. USA, Pearson Education, p. 169.
[2] Jhamat Naveed, Arshad Zeeshan, Mustafa Ghulam. (2021). Historical perspective of software refactoring tools towards future solution. Journal of the Punjab University Historical Society, vol. 34, no. 1, pp. 173–179.
[3] Gamma, E. Helm, R. Johnson, Vlissides, J. (1994). Design Patterns: Elements of reusable object-oriented software. USA, Addison-Wesley, pp. 87, 97, 139, 175 223, 305.
[4] Kerievsky, J. (2001). Refactoring to patterns. Industrial Logic Inc. p. 169.
[5] Shvets, A. (2019). Sumergete en los patrones de diseño. Obtenido de Refactoring.Guru: https://refactoring.guru/es/design-patterns/, obtenido el 28 de mayo de 2022.