Tiempo de lectura: 5 minutos

Patrones de diseño: Introducción.

Antes de iniciar una serie de post sobre los patrones de diseño que más uso, me veo un poquito con la obligación de hacer una introducción. Esta introducción la subdividiré en dos partes:

  1. Trataré mi experiencia personal sobre el uso de patrones.
  2. Haré un resumen de varios libros y apuntes sobre qué es para ellos los patrones de diseño. Me niego a poner mi cabeza a cien para pensar en definiciones que ya están más que habladas 😛

Cuando estás en la Universidad y te hablan de patrones de diseño, los ves como una cosa más dentro del desarrollo de software que hay que dar, pero a medida que vas desarrollando aplicaciones, te das cuenta que esas clases tenían más importancia de la que se da.

El poder identificar un problema una y otra vez, sea cual sea el proyecto y aplicar el patrón correcto es algo que se aprende con el buen conocimiento de los patrones y la propia experiencia.


Para mi, son múltiples las ventajas que me da los patrones, pero principalmente destaco el hacer un código “entendible” para otros compañeros, hacerlo reusable y el desacoplarlo de librerías o frameworks. Tenemos que tener muy en cuenta el separar la lógica de negocio con la lógica de modelos de datos.

Vayamos con definiciones:

¿Qué es un patrón de diseño?.

Según Christopher Alexander:”….cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, así como la solución a ese problema, de tal modo que se pueda aplicar esta solución un millón de veces, sin hacer lo mismo dos veces.” Aunque esta definición se refiere a patrones de ciudades y edificios, también valdría para el desarrollo de patrones en la programación.

Clasificación de los patrones.

Los patrones de diseño se pueden clasificar en tres grupos según su propósito:

  • De creación. Son aquellos que están relacionados con la creación de objetos.
  • Estructurales. Tratan con la composición de clases u objetos.
  • De comportamiento. Caracterizan el modo en que las clases y objetos interactúan y se reparten la responsabilidad.

Todo esto queda muy bien sobre el ‘papel’ así que veamos ahora ejemplos de cada uno. La lista de patrones la iré actualizando.

  1. Patrones de Creación
    1. Singleton. Garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia. Restringe la instanciación de una clase o valor de un tipo a un solo objeto.
    2. Abstract Factoy. 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. El problema a solucionar por este patrón es el de crear diferentes familias de objetos, como por ejemplo la creación de interfaces gráficas de distintos tipos (ventana, menú, botón, etc.).
    3. Factory Method. centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística, es decir, la diversidad de casos particulares que se pueden prever, para elegir el subtipo que crear. Parte del principio de que las subclases determinan la clase a implementar.
    4. Builder. Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto.
    5. Prototype. crea nuevos objetos clonándolos de una instancia ya existente.
  2. Patrones Estructurales
    1. Adapter. Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría utilizarla.
    2. Bridge. Desacopla una abstracción de su implementación.
    3. Composite. Permite tratar objetos compuestos como si de uno simple se tratase.
    4. Decorator. Añade funcionalidad a una clase dinámicamente.
    5. Facade. Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema.
    6. Proxy. Mantiene un representante de un objeto.
    7. Module. Agrupa varios elementos relacionados, como clases, singletons, y métodos, utilizados globalmente, en una entidad única.
    8. Repository. El patrón repositorio nos permite tener una abstracción de la implementación de acceso a datos en nuestras aplicaciones, de modo que nuestra lógica de negocio no conozca ni esté acoplada a la fuente de datos.
  3. Patrones de Comportamiento
    1. Chain of Responsability. Cadena de Responsabilidad. Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada.
    2. Command. Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
    3. Interpreter. Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo.
    4. Observer. 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.
    5. Visitor. Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera.
    6. Template Method. 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.

Fuente Bibliográficas:

  1.  Libro “Patrones de diseño” – Erich Gamma. Podéis encontrar el libro aquí: Patrones de diseño de Erich Gamma
  2. Libro “Head First Design Patterns” – Elisabeth Freeman, Eric Freeman, Bert Bates, Kathy Sierra. Podéis encontrar el libro aquí: Head First Design Patterns
  3. Web MSDN Microsoft – Patterns