Patrones de Diseño (I – Introducción)

Uno de mis objetivos para el blog, es el de realizar un monográfico sobre los patrones de diseño: qué son, cuándo usarlos, de dónde vienen y cómo se implementan.

Así que sin más dilación, empiezo con el primero de muchos post. Espero muchas críticas y sobre todo, que os sirva de algo.

¿Qué son los patrones de diseño?

En el contexto del diseño orientado a objetos, son soluciones a problemas de diseño comunes. Para ser patrones, dichas soluciones deben poseer las siguientes características:

  1. Son reusables: para problemas de diseño similares, la solución puede ser usada como solución (de ahí la palabra «patrón»).
  2. Son efectivas: han sido usadas y probadas tantas veces que se puede confiar en la eficacia y robustez de la solución.

Evidentemente, al ser soluciones realizadas una y otra vez con la misma estructura, además del alivio virtual que nos supone que ya existe gente que ha probado el diseño hasta la saciedad, tenemos la ventaja de que parte de esa gente ha agrupado en catálogos patrones para describir en ellos los contextos en los que se pueden usar y cómo usarlos.

Dichos catálogos se pueden clasificar en dos grupos bien diferenciados, los dedicados a los patrones de diseño genéricos y los patrones de diseño específicos de un dominio (como pueden ser, por ejemplo patrones de diseño para el desarrollo de interfaces de usuario).

Para este conjunto de entradas sólo voy a hablar de los patrones definidos por el GoF en su libro “Design Patterns. Elements of Reusable Object-Oriented Software”. Éste engloba los patrones de diseño que aparecen en el «Code Complete» de Steve McConnell, además de añadir unos cuantos propios. Aún así en al bibliografía hay enlaces a otros catálogos de patrones.

En su libro, los Cuatro describían una serie de patrones que a lo largo de su carrera habían detectado como soluciones. Decidieron agrupar el catálogo de patrones en tres conjuntos que representarían su cometido: creación, composición y comportamiento.

Paso a enumerarlos y a dar una pequeña descripción. Desde luego, intentar resumir en una frase lo que significan los patrones es un crimen. Espero que los que sepan no me lapiden (mejor si me ayudan a intentar ofrecer un mejor resumen explicarlo mejor). La idea es que una vez se hayan escrito los artículos, este artículo sirva de referencia.

Patrones de creación

Son solucines a problemas relativos al proceso de creación de objetos. En el libro, los autores definen cinco patrones:

  • Abstract Factory: cómo crear objetos de la misma familia sin especificar directamente las implementaciones.
  • Builder: separa el proceso de creación de un objeto complejo de la representación del objeto en sí. Así podemos usa el mismo proceso de construcción para crear representaciones diferentes.
  • Factory Method: define la interfaz de creación de un objeto, dejando su proceso de creación a la clase que la implementa.
  • Prototype: crea objetos a partir de la clonación de objeto prototipo de la misma clase.
  • Singleton: crea un único objeto de una clase en particular.

Patrones estructurales

Éstos patrones definen cómo estructurar o disponer los objetos ante determinadas situaciones. El el libro se definen siete patrones diferentes:

  • Adapter: «adapta» la interfaz de una clase servidora a una interfaz comprensible para una clase cliente.
  • Bridge: separa de una abstracción respecto a su implementación, de tal forma que pueden ser modificadas si afectarse mutuamente.
  • Composite: cómo componer un objeto de tal forma que sus partes y el todo pertenecen a la misma estructura jerárquica (y por tanto son similares).
  • Decorator: añade funcionalidades o responsabilidades dinámicamente a un objeto.
  • Facade: especifica una única interfaz que engloba las funcionalidades ofrecidas por un conjunto de interfaces.
  • Flyweight: compartición de objetos para minimizar su uso.
  • Proxy: crea un objeto intermediario entre el objeto cliente y servidor de tal forma que podemos controlar el acceso a éste.

Patrones de comportamiento

Definen relaciones entre objetos y cómo éstos se reparten sus responsabilidades entre sí. Se definen once patrones:

  • Chain of Responsibility: una secuencia o cadena de objetos por la que pasa una petición, actuando éstos en consecuencia
  • Command: una forma de actuar ante una petición cuando no conocemos los detalles de ésta ni quién se encarga de actuar sobre ella.
  • Interpreter: definición de una gramática más una forma de interpretarla.
  • Iterator: patrón para recorrer secuencialmente una colección de elementos sin conocer realmente la implementación de dicha colección.
  • Mediator: objeto que encapsula la relación entre un conjunto de objetos evitando que los objetos se relacionen entre sí directamente.
  • Memento: almacena el estado de un objeto en un momento dado.
  • Observer: objeto/s que reaccionan en el momento que el objeto con el que están relacionados cambian de estado.
  • State: cambia el comportamiento de un objeto dependiendo del estado en el que se encuentre.
  • Strategy: define una familia de algoritmos más una interfaz que los encapsula de tal forma el el cliente use el interfaz, independientemente de la implementación de dicho algoritmo.
  • Template Method: método abstracto perteneciente a un algoritmo de una superclase que las subclases deberán implementar.
  • Visitor: o cómo separar un algoritmo de unas estructura sobre la que trabaja.

¿Cuándo, por qué y cómo usarlos?

Esto depende principalmente del contexto del problema y del patrón a usar. Estas preguntas serán resueltas en los sucesivos post dedicados a cada uno de los patrones (además de mejores explicaciones, ejemplos y dibujitos).

Saludos y disfrutad de la semana

Bibliografía