“Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno y describe también el núcleo de la solución al problema, de forma que puede utilizarse un millón de veces sin tener que hacer dos veces lo mismo.”

Christopher Alexander

Como había quedado esta es la segunda entrega sobre arquitectura de software, esta vez enfocada a los patrones de diseño los cuales describen un problema que ocurre en repetidas ocasiones en algún contexto determinado de desarrollo de software, y entregan una buena solución. Esto ayuda a diseñar correctamente en menos tiempo, evitando los errores que tan comúnmente se atribuyen a la etapa del diseño de software.

Un patrón de diseño es una solución a un problema que ya ha sido resuelto satisfactoriamente en ocasiones anteriores y a su vez puede ser reusable (aplicable a diferentes problemas de diseño en distintas circunstancias).
Siendo estos la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Al día de hoy es recomendable realizar un análisis, diseño e implementación orientado a objetos, a no ser que exista una excepción requerida por las circunstancias de la aplicación o campo en el que nos movemos.
Para la parte de análisis y diseño se recomienda utilizar el Lenguaje de Modelado Unificado (UML por sus siglas en ingles).

Análisis Orientado a Objetos

En el análisis se estudia el dominio del problema para construir un modelo del mundo real utilizando objetos. Se investiga para hacer una descripción del problema y obtener todos los requerimientos necesarios.
Se realiza una investigación del problema.
Durante el Análisis, se enfatiza en encontrar y describir los objetos (o conceptos) en el dominio del problema.
Por ejemplo: conceptos en un sistema de información para una librera incluyen Libros, Librería.
El Énfasis es en la investigación del problema y sus requisitos (mas que en una solución)
Se resume en: Haz lo correcto (Do the Right Thing)

Diseño Orientado a Objetos

Se enfatiza una solución conceptual que satisface los requerimientos.
Se necesita definir objetos software y como colaboran entre si para satisfacer los requerimientos.
Por ejemplo: en el sistema de información de una librería el objeto software “libro” debería tener un atributo “titulo” y un método obtenerCapitulo();
Diseños son implementados en un lenguaje de programación
Se resume en; Haz las cosas bien. (Do the thing right)
A pesar del esfuerzo realizado en las etapas anteriores surgen problemas debido al uso inapropiado de la orientación a objetos, una muy común es el mal empleo de la encapsulación.

Otro de los problemas fundamentales es el vacio que existe entre el análisis, diseño e implementación, que hace que el programador tenga la necesidad de tomar decisiones de diseño.

Para solventar dichos problemas se produce un nuevo enfoque: el diseño con patrones. La idea fue propuesta inicialmente por el arquitecto Christopher Alexander, que aplica el concepto a la construcción de edificios en menos tiempo con la publicación de su libro “The Ti­meless Way of Building” en el año de 1979.
No obstante, no fue hasta principios de los 90’s cuando los patrones de diseño tuvieron gran Éxito en el mundo de la informática a partir de la publicación del libro Design Patterns escrito por el GoF (Gang of Four) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides, en el que recogían 23 patrones de diseño comunes.

Objetivos de los patrones
Los patrones de diseño pretenden:

• Proporcionar catálogos de elementos reusables en el diseño de sistemas de software.
• Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
• Formalizar un vocabulario común entre diseñadores.
• Estandarizar el modo en que se realiza el diseño.
• Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando el conocimiento ya existente.
• Sin embargo, no se pretende obligar a utilizar los patrones de diseño siempre, solo en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. Abuzar o forzar el uso de los patrones puede ser un error.

Clasificación de los patrones
Según la escala o nivel de abstracción:

• Patrones arquitecturales: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas software.
• Patrones de Diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas software.
• Idiomas: Patrones bajo nivel específicos para un lenguaje de programación o entorno concreto.

Según el propósito: Qué hace el patrón.

• Patrones de Creación: para creación de instancias.
• Patrones estructurales: relaciones entre clases, combinación y formación de estructuras mayores.
• Patrones de Comportamiento: Interacción y cooperación entre clases.

Patrones Creacionales

• Abstract Factory (Fábrica abstracta): Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí­ y haciendo transparente el tipo de familia concreta que se esté usando.
• Builder (Constructor virtual): Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un Único punto.
• Factory Method (Método de fabricación): Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística para elegir el subtipo que crear.
• Prototype (Prototipo): Crea nuevos objetos clonÁndolos de una instancia ya existente.
• Singleton (Instancia Única): Garantiza la existencia de una Única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia.

Patrones Estructurales

• Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podrá utilizarla.
• Bridge (Puente): Desacopla una abstracción de su implementación.
• Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase.
• Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente.
• Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema.
• Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información.
• Proxy: Mantiene un representante de un objeto.

Patrones de Comportamiento

• Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada.
• Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
• Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así­ como las herramientas necesarias para interpretarlo.
• Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos.
• Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto.
• Memento (Recuerdo): Permite volver a estados anteriores del sistema.
• Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de Él.
• State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.
• Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución.
• Template Method (Método plantilla): Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.
• Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera.

Conclusiones

La idea de los patrones ha adquirido gran popularidad. En el ámbito de la ingeniería de software; se están desarrollando muchos proyectos de investigación al respecto. No sólo se están aplicando en los llamados patrones de diseño, sino que la idea esta transportándose a otras actividades del desarrollo de software.

El concepto de patrón tiene carácter general y por consiguiente es aplicable a un sin número de situaciones de diferentes tipo, estilo, entorno, etc. En lo referente al software, la aplicación de los patrones esta siendo utilizada con éxito en muchos ámbitos de la ingeniería de software. En definitiva está mejorando las prácticas en el desarrollo de sistemas de información.

Donde exista la posibilidad de aplicación del criterio profesional experimentado, a un problema recurrente, la idea de patrones de Alexander podrá usarse para reutilizar y transmitir dichas experiencias a profesionales menos experimentados.

Por lo tanto podemos resumir un patrón con los siguientes puntos:

• Un Patrón de Diseño, es un conjunto de información que describe una solución recurrente a un problema de diseño no trivial.
• La efectividad de esta solución ha debido ser probada muchas veces por profesionales expertos dentro de un contexto determinado en situaciones anteriores.
• Esta solución debe ser reutilizable, para problemas de diseño similares en distintas circunstancias.
• Esta descripción de un patrón debe ser lo suficientemente explícita para que pueda ser transmitida a profesionales no expertos”.

Bibliografía

Design Patterns. Elements of Reusable Object-Oriented Software - Gamma, Helm, Johnson, Vlissides - Addison Wesley
UML y Patrones. Introducción al análisis y diseño orientado a objetos - Larman - Prentice Hall
Patrones de diseño - Wikipedia