Design patterns: programar de manera más rápida y segura

Cada diseño tiene su patrón y todo tiene su propio modelo, sea una taza, una casa o un vestido. A nadie se le ocurriría la idea de poner el asa de una taza al interior de la misma, ya que para la uti­li­za­ción práctica está de­mo­s­tra­do que es mejor colocar este elemento en el exterior. Por esto, si vas a un curso de alfarería y quieres hacer una vasija con asas, ya conoces la forma básica; en tu cabeza ya está guardada como patrón de diseño.

El mecanismo es similar con los programas in­fo­r­má­ti­cos. Hay de­te­r­mi­na­dos procesos que siempre se repiten, de tal forma que solo hay que dar un pequeño paso para crear un patrón. A co­n­ti­nua­ción ex­pli­ca­mos cómo estos design patterns (patrones de diseño) te pueden facilitar las tareas de pro­gra­ma­ción.

Entonces, ¿Qué son los design patterns? Vamos a continuar uti­li­za­n­do nuestro ejemplo anterior: para cada taza —ya sea de café o de té— siempre se necesitan los mismos elementos básicos: base, paredes y asa. Esto sucede de manera similar en la pro­gra­ma­ción: los bucles que se deben recorrer siempre están vi­n­cu­la­dos a los re­qui­si­tos iniciales y finales; una condición siempre requiere una decisión sobre lo que ocurre si se cumplen estos re­qui­si­tos y lo que ocurre si no se cumplen; un cálculo siempre da como resultado la co­m­bi­na­ción de variables, etc. A partir de muchos de estos pasos de pro­gra­ma­ción in­di­vi­dua­les se crea una secuencia de programa que siempre se de­sa­rro­lla de la misma manera para de­te­r­mi­na­das tareas. Los patrones de diseño de software son una de­s­cri­p­ción de cómo resolver un problema.

A co­n­ti­nua­ción pre­se­n­ta­mos un ejemplo muy sencillo de un software pattern, en este caso, un factory pattern:

Lo mismo es aplicable a contextos y procesos más amplios que se utilizan de manera re­cu­rre­n­te para resolver ciertas tareas en las se­cue­n­cias de programas. El ejemplo de código se puede ampliar a voluntad y también aplicar a otros sectores, productos y procesos di­fe­re­n­tes. Además, por supuesto, solo se trata de un co­m­po­ne­n­te dentro un software más completo. De esta forma, los patrones de diseño se entienden como esquemas que ya se han probado en la práctica.

Los tipos de patrones de diseño re­pre­se­n­tan las áreas de apli­ca­ción básicas de los patrones de software que reúnen.

Los stru­c­tu­ral patterns son pla­n­ti­llas ya listas para re­la­cio­nes entre clases. El objetivo es lograr una ab­s­tra­c­ción que también se pueda comunicar con otros enfoques de solución. El concepto clave es la pro­gra­ma­ción de in­te­r­fa­ces.

Con los beha­vio­ral patterns se modela el co­m­po­r­ta­mie­n­to del software. Estos patrones si­m­pli­fi­can los complejos procesos de control. Para ello, se puede elegir entre al­go­ri­t­mos y las re­s­po­n­sa­bi­li­da­des de los objetos.

Con los crea­tio­nal patterns se crean objetos que permiten una re­pre­se­n­ta­ción si­m­pli­fi­ca­da de los procesos para de­te­r­mi­na­das in­s­ta­n­cias. Este proceso funciona in­de­pe­n­die­n­te­me­n­te de la manera en la que cada uno de los objetos se cree y se re­pre­se­n­te en un software.

Con el paso del tiempo, han surgido más tipos de patrones de diseño que no encajan en ninguna de las ca­te­go­rías me­n­cio­na­das. Entre ellos se en­cue­n­tran los patrones para el mapeo objeto-re­la­cio­nal, con los que se almacenan los objetos y sus re­la­cio­nes en una base de datos re­la­cio­nal.

La po­si­bi­li­dad de recurrir a pla­n­tea­mie­n­tos de solución probados va aco­m­pa­ña­da de un ahorro de tiempo y costes. Los equipos de de­sa­rro­lla­do­res no necesitan inventar una y otra vez la máquina para resolver, en cada nuevo flujo de programa, subtareas que ya se han resuelto en multitud de ocasiones. Las de­no­mi­na­cio­nes de los patrones suelen provenir de un vo­ca­bu­la­rio de diseño común que si­m­pli­fi­ca tanto la co­mu­ni­ca­ción entre de­sa­rro­lla­do­res como con el usuario de la futura solución. También la do­cu­me­n­ta­ción de un software se si­m­pli­fi­ca cuando se utilizan co­m­po­ne­n­tes ya do­cu­me­n­ta­dos. Estas ventajas también se apro­ve­chan durante el ma­n­te­ni­mie­n­to y posterior de­sa­rro­llo de un programa.

El tra­ta­mie­n­to de los patrones de diseño requiere amplios co­no­ci­mie­n­tos previos. La di­s­po­ni­bi­li­dad de los design patterns también puede inducir a creer que, si se cuenta con patrones de diseño, apa­re­n­te­me­n­te todos los problemas quedan resueltos. En resumen: la crea­ti­vi­dad puede quedar limitada, al igual que la cu­rio­si­dad para encontrar nuevas (y mejores) so­lu­cio­nes.

Existen más de setenta patrones de diseño que pe­r­te­ne­cen a di­fe­re­n­tes ca­te­go­rías. Algunos software patterns im­po­r­ta­n­tes son, por ejemplo, los si­guie­n­tes:

• Builder pattern: el co­n­s­tru­c­tor de la categoría del patrón de creación separa el de­sa­rro­llo de objetos (complejos) de sus re­pre­se­n­ta­cio­nes.
• Factory pattern: este patrón de diseño genera un objeto a modo de patrón de creación re­cu­rrie­n­do a un método en lugar de un co­n­s­tru­c­tor.
• Singleton pattern: la instancia única garantiza, como patrón de creación, que úni­ca­me­n­te exista solo un objeto en cada clase. Además, el singleton está di­s­po­ni­ble a nivel global.

• Composite pattern: un patrón de es­tru­c­tu­ra compuesto que está es­pe­cia­l­me­n­te orientado al tra­ta­mie­n­to de es­tru­c­tu­ras dinámicas, por ejemplo para la or­ga­ni­za­ción de archivos o la co­m­pre­sión de datos.
• Decorator pattern: el llamado decorador integra más funciones o co­m­pe­te­n­cias en clases exi­s­te­n­tes.
• Facade pattern: la fachada re­pre­se­n­ta la interfaz para los demás sistemas y sub-sistemas.

• Observer pattern: el ob­se­r­va­dor transmite las mo­di­fi­ca­cio­nes de un objeto a es­tru­c­tu­ras que dependen del objeto inicial.
• Strategy pattern: la es­tra­te­gia define una familia de al­go­ri­t­mos in­te­r­ca­m­bia­bles.
• Visitor pattern: el visitante aísla ope­ra­cio­nes eje­cu­ta­bles, de tal forma que se puedan llevar a cabo nuevas ope­ra­cio­nes sin modificar las clases afectadas.