Patrones de diseño

Los patrones de diseño son soluciones reutilizables para problemas comunes en el diseño de software.

Surgen cuando los programadores e ingenieros de software se dan cuenta que los problemas con los que se enfrentan en diferentes proyectos son muy similares entre sí y se pueden resolver utilizando las "mismas" soluciones.

Así se crean ciertas soluciones independientes del lenguaje de programación que constituyen lo que hoy conocemos como "patrones de diseño".

Los patrones de diseño se introdujeron a finales de los ochenta pero alcanzaron su popularidad en 1994 al publicarse el libro "Design Patterns: elements of reusable object-oriented software" publicado por los autores Erich Gamma, Richard Helm, Ralph Jonson y John Vlissides (conocidos como Gang of Four o GoF). Los patrones publicados en ese libro se denominan patrones GoF.

En total se definen 23 patrones de diseño clásicos divididos en tres grupos:

  • Patrones estructurales: son patrones de diseño utilizados para definir estructuras de objetos y clases que van a trabajar juntos. En esta categoría tendríamos los patrones Adapter, Decorator y Façade.
  • Patrones de comportamiento: patrones relacionados con la forma de establecer la comunicación entre diferentes objetos y clases. Este grupo estaría formado por los patrones Strategy, Observer y State.
  • Patrones de creación: utilizados para encapsular y ocultar la lógica relacionada con la creación de los propios objetos. En este grupo tenemos los patrones Singleton , Abstract Factory y Factory.

Hay que tener en cuenta que los patrones nos presentan dos ventajas fundamentales:

  • Proporcionan una posible solución inicial a un problema.
  • Dan un método sencillo de comunicación entre programadores. Después de estudiar y conocer los patrones de diseño podemos definir con mayor claridad la solución que hemos dado a nuestro problema haciendo referencia al patrón utilizado. Es decir, ya no tenemos que decir "he utilizado una clase estática que recoge los datos de la conexión a las base de datos y los mantiene durante la ejecución del programa", nos basta con "he utilizado un patrón Singleton para mantener la conexión a la base de datos".

Por tanto, si utilizamos patrones de diseño en nuestras aplicaciones vamos a crear sistemas más robustos, escalables y con un mantenimiento más sencillo dado que seguimos un estándar establecido, similar a los que existen en otras ingenierías.

Quizá el problema más grave sea localizar el patrón de diseño a utilizar ante cada problema. Desgraciadamente no existe ninguna regla que relacione patrones con problemas si no que (como prácticamente todo en programación) se determinan a partir de la experiencia.

Lo más importante a la hora de decidir el patrón de diseño a utilizar es separarse durante un momento del código y mirar el problema desde una perspectiva superior fijándonos en las relaciones entre las clases.

Los patrones de diseño también conllevan ciertos riesgos. El más importante quizá sea el de construir toda una solución alrededor de un patrón de diseño simplemente por el hecho de utilizarlo. Hay que tener en cuenta que los patrones son "indicaciones" y herramientas. No son "obligaciones". Nos proporcionan una guía que en la mayor parte de los casos podemos seguir pero que además podemos modificar y ampliar para que se acomode mejor a nuestro problema en particular. No deberíamos obsesionarnos con utilizar un patrón en particular para resolver un problema, en algunos casos quizá sea mejor utilizar otros métodos.

Aparte de los "patrones de diseño" también se pueden llegar a definir "antipatrones". Un antipatrón, como su propio nombre indica, es lo contrario a un patrón, son todas aquellas prácticas que deberíamos intentar evitar a toda costa. Los antipatrones se definen no solo a nivel de programación si no también a nivel de metodología o de gestión del equipo.


El patrón Singleton

El patrón Singleton nos asegura que una clase proporciona un único acceso global a un objeto. Resulta muy útil cuando deseamos que una aplicación acceda a un objeto desde un único punto y a partir de una única copia en memoria.

Uno de los ejemplos más claros de utilización del patrón Singleton es para acceso a base de datos donde queremos que todas las clases de nuestra aplicación accedan a una única conexión.

Leer más...

22-05-2013

Clases Singleton frente a clases estáticas

En el caso de desarrollar un patrón Singleton tenemos la duda de si merece la pena realmente o es mejor utilizar simplemente una clase estática .

Como siempre en estos casos, la mayoría de las veces es más una cuestión de gustos que una decisión realmente técnica aunque hay razones que nos llevan a pensar que utilizar un patrón Singleton es una mejor opción.

Leer más...

22-05-2013