Decisiones de diseño no empaquetadas, sino regulares
Estado actual de esta publicación: Borrador inicial.
¿Qué sería lo recomendable sobre patrones de diseño hoy en día?
Primero, recomendaría analizar las propiedades externas por lograr al aplicar determinado patrón de diseño. Algún patrón de diseño podría mejorar más ciertas propiedades en comparación con un patrón distinto. Por ejemplo, exactitud y robustez son propiedades externas básicas de un software que vale la pena ser escrito; es decir, si vamos a crear software, entonces acordemos que tendrá al menos las propiedades más básicas de calidad que lo harán confiable: Exactitud es la capacidad del software para comportarse según lo definido en su especificación funcional*. Robustez es la capacidad del software para reaccionar apropiadamente ante condiciones anormales de operación. Asimismo, hay propiedades que hacen que el software sea modular: Extensibilidad es la facilidad de adaptación del software ante cambios en su especificación. Reutilización es la habilidad de los componentes de software para servir en la construcción de muchas aplicaciones diferentes. No todos los patrones mejoran de la misma manera dichas propiedades para una solución particular. Por lo que aplicar patrones de diseño no mejorará automágicamente una solución en la dirección deseada a menos que el diseñador sepa lo que está haciendo.
*Segundo, aplicar patrones para desacoplar las dependencias hacia recursos y servicios externos (conexiones de red, bases de datos, servicios de mensajería, herramientas de monitoreo, proveedores de “nube”, etc.). Así, los casos de uso de los componentes de software de la solución podrán ser especificados de manera ejecutable y concreta; es decir, la especificación funcional de la solución podrá ser no un texto estático, sino una especificación funcional ejecutable compuesta de la ejecución por demanda de casos repetibles y automáticos. Lo cual no es otra cosa que una consecuencia natural de las técnicas de diseño de software conocidas como test-driven design y automated user acceptance testing. (nota: aclaro que estas son técnicas de diseño, no de pruebas para validación y verificación; para diseñar una estrategia de pruebas se requieren profesionales de ese campo, el cual es distinto del campo de quienes crean las soluciones). Ese desacoplo de dependencias permite especificar el comportamiento exacto esperado (precondiciones, invariantes, postcondiciones) de la solución tanto para los casos funcionales como para los casos de administración operacional (monitoreo, diagnóstico y remediación) ante condiciones anormales de operación.
Tercero, recomendaría analizar las propiedades internas por lograr al aplicar determinado patrón de diseño. Algún patrón de diseño podría mejorar más ciertas propiedades internas en comparación con un patrón distinto. Las propiedades internas del software las determina la tensión entre cohesión y acoplamiento. Una evidencia concreta cuantificable para discriminar entre el efecto de diferentes patrones de diseño en una situación particular sería la métrica más cercana al Main Sequence en el diseño en cuestión.
Cuarto, recordaría que desde los inicios de la idea de ‘patrones de diseño’ se ha hecho notar que este tipo de técnicas requiere considerar un tipo particular de retrabajo para la aplicación y adaptación de un patrón de diseño a una situación particular. Una buena planeación considera ese tipo de retrabajo. Un rasgo de ese tipo de retrabajo es que no impacta de manera negativa las métricas de eficiencia por ciclo de liberación; es decir, no aumenta las métricas de cantidad de trabajo en curso (work in progress).
Quinto, sería recomendable pensar la historia de lo propuesto bajo el nombre de ‘patrones de diseño’. Recuerdo, en la primera mitad de los años 90 del siglo pasado, saber de un conferencista en un evento de OOPSLA reconocer «No sabemos qué son los patrones de diseño», lo cual me pareció honesto de su parte en esa época. Asimismo, recuerdo en esa misma época enterarme del inicio de las conferencias PLoP por parte de quienes proponían respuestas provisionales, pero concretas, a la pregunta «¿Qué es un patrón de diseño?»
Sexto, recomendaría poco a poco adquirir hábitos para diseñar de manera reflexiva para así aumentar la destreza propia para identificar patrones tanto en el espacio del problema como en el de la solución.
