¡Saludos visitante! si deseas comentar o hacer una pregunta sobre este post por favor dirígete a la nueva dirección en http://variabletecnica.com.ve. La página que estás leyendo dejará de estar disponible el 15/11/2015. Gracias, y disculpa las molestias 🙂

Las últimas dos semanas he estado leyendo un interesante libro sobre Algoritmos Evolutivos, y para poner en práctica lo que vaya aprendiendo voy a implementar en JAVA los algoritmos a medida que los estudie.

Lo interesante del libro es que los algoritmos están planteados en pseudo código y sin seguir ningún paradigma de programación específico (a veces parece modular y a veces orientado a objeto); y como tengo libertad de implementarlos como quiera, lo haré Orientado a Objetos. Así, puedo matar dos pájaros de un tiro: aprendo Algoritmos Evolutivos, y practico los Principios de la Programación Orientada a Objetos y los Patrones de Diseño Orientado a Objetos.

Este artículo será una breve introducción a los patrones de diseño, mientras preparo uno o dos artículos más sobre patrones de diseño específicos, tentativamente Factory Method y Strategy, que me serán útiles en el diseño de mi primer ejercicio de Algoritmos Genéticos.

Definamos Patrón de Diseño

Un Patrón de Diseño es una vía formal de documentar una solución a un problema de diseño en un campo particular de experiencia. La idea fue presentada originalmente por el arquitecto Christopher Alexander en el campo de la arquitectura, y ha sido adaptado para varias otras disciplinas de ingeniería.

Un patrón documenta un par problema-solución recurrente dentro de un contexto dado. Un patrón, sin embargo, es más que sólo el problema o la estructura de la solución: se incluye tanto el problema como la solución, junto con la lógica que los une. Un problema se considera con respecto a las fuerzas en conflicto (por ejemplo, mantenibilidad vs. reusabilidad), detallando por qué el problema es un problema. Una solución propuesta se describe en términos de su estructura, e incluye una presentación clara de las consecuencias, tanto los beneficios como los inconvenientes, de la aplicación de la solución.

En la Ingeniería del software se encuentra una gran cantidad de patrones que solucionan una amplia gama de problemas comunes. Entre ellos, y gracias al auge de la programación orientada a objetos, ha sido posible recolectar y documentar catálogos de aquellos que ha sido más eficaces para resolver los problemas más comunes de diseño. Uno de estos catálogos es el reconocido «Design Patterns: Elements of Reusable Object-Oriented Software» (Addison Wesley, ISBN: 0201633612), del cual derivan otros catálogos más recientes.

¿Y para qué sirven los Patrones de Diseño

Como mencioné un poco más arriba, en la ingeniería de software nos topamos con ciertos problemas que se repiten frecuentemente, y para los cuales, luego de aplicar los Principios de Diseño Orientado a Objetos (Single responsibility, Open-closed, Liskov substitution, Interface segregation, Dependency inversion, y otros…), generalmente llegamos a las mismas soluciones. En cierto modo, un Patrón de Diseño es «la solución más natural a cierto tipo de problema común».

Viéndolo de ese modo, parece lógico pensar que cuando nos topemos con uno de esos «problemas modelo» podríamos aplicar «la solución conocida», sin tener que reinventar la rueda. Claro que, antes de aplicar un patrón, debemos asegurarnos de que nuestro problema encaja con el modelo, y de que las consecuencias del patrón (buenas o malas) se adaptan a nuestro caso: La idea no es que tratemos de usar patrones aquí y allá, si no que los usemos cuando encajen con el problema de diseño que queremos solucionar.

Un ejemplo ilustrativo

En .NET framework, la clase DataRow no tiene un constructor público, por lo cual no puedes crear una nueva instancia usando instrucción new, sino que debes pedirle a una instancia de DataTable que cree un DataRow por ti mediante la función NewRow:

'Puedes crear un nuevo DataTable usando "New"
Dim NuevaTabla As New System.Data.DataTable("Personas")
NuevaTabla.Columns.Add("Id", Type.GetType("System.Integer"))
NuevaTabla.Columns.Add("Nombre", Type.GetType("System.String"))
NuevaTabla.Columns.Add("Nacimiento", Type.GetType("System.Date"))

'Pero no un nuevo DataRow...
Dim NuevaFila As System.Data.DataRow
NuevaFila = NuevaTabla.NewRow() 

'Por cierto: la nueva fila no se agrega automáticamente,
'recuerda agregarla manualmente a la colección de filas:
NuevaTabla.rows.Add(NuevaFila)

Así, vemos que estas dos clases implementan el patrón de diseño Factory Method (del que ablaré en mi próximo artículo), donde la clase DataTable actúa como fábrica, y la clase DataRow es el producto concreto.

Si tienes alguna experiencia con Patrones de Diseño OO, o con estas dos clases, te habrás dado cuenta de porqué usar este patrón en lugar de dejarte crear los renglones «a mano»: todos los renglones de una tabla deben tener los mismos campos (columnas), ya sabes: mismos nombre, tipo, orden, restricciones… y si te dejaran crear las filas «manualmente» tendrías que indicar cada vez todas las columnas que tiene la fila.

De este modo este patrón «automatiza» el complejo proceso de crear una fila (producto) y lo encapsula en un método de otra clase (la fábrica) que en este caso ni siguiera requiere parámetros: cada instancia de la clase DataTable tiene toda la información necesaria para crear las filas (instancias de la clase DataRow) que la conforman.

Esto, a su vez explica porqué no podemos «mover» una fila de una tabla a otra: cada fila está asociada a su tabla «padre» (la propiedad DataRow.Table, que es de solo lectura), por lo cual no te permite ni siquiera mover la fila a otra tabla que tenga la misma estructura que la original.

Para terminar, quisiera resaltar que es posible identificar muchos otros ejemplos de patrones de diseño tanto en .NET como en java; esta es una muy breve lista ilustrativa:

• Builder Pattern: en las clases java.lang.StringBuilder (Java) y System.Text.StringBuilder (.NET)
• Decorator Pattern: muchas de las clases de los espacios de nombres java.io (java) y System.IO (.NET)
• Memento Pattern: en cualquier lenguaje de programación al usar clases de serialización y deserialización.
• Iterator Pattern: java.util.Iterator (Java) y System.Collections.IEnumerator (.NET)
• Prototype Pattern: implementada en el método Clone() de java.lang.Object (Java) y System.Object (.NET)

Derecho de uso

Los contenidos generados por el autor de este artículo (explicaciones, código fuente, y archivos adjuntos creados por el autor) están disponibles bajo licencia CC BY-SA 3.0, y pueden ser usados, derivados y compartidos bajo los términos indicados en la misma. Los contenidos no generados por el autor de este artículo son propiedad de sus respectivos dueños y están regidos por las licencias que ellos hayan dispuesto.

Cita del día

«Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.»
Christopher Alexander

The most important knowledge of software patterns is the knowledge of when to apply them and when not to apply them…there is no one-size-fits-all solution.
Randy Stafford, «97 Things Every Software Architect Should Know»