GANG OF FOUR (GoF)
Patrones de diseño Gang of Four
Hermes Gil
Politecnico Grancolombiano
Abstract
Los patrones de diseño “Gang of Four” o “Pandilla de los 4”, son 23 tipos de patrones
enumerados en el libro “Design Patterns”. Gamma, Helm, Johnson, Vlissides. 1995, y sirven
para enfrentarse para problemas comunes y concretos.
Patrones GoF
El término de patrón fue dado por primera vez en el año 1977 por el arquitecto
Christopher Alexander, quien dio en su libro A Pattern Language la siguiente definición:
“Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, para
describir después el núcleo de la solución a ese problema, de tal manera que esa solución
pueda ser usada más de un millón de veces sin hacerlo ni siquiera dos veces de la misma
forma”. En la ingeniería del software, un patrón constituye el apoyo para la solución a los
problemas más comunes que se presentan durante las diferentes etapas del ciclo de vida del
software. Ahora bien, los patrones de diseño según The Gang of Four -GOF- “describen
soluciones simples y elegantes a problemas específicos en el diseño de software orientado a
objetos” (Gamma et al, 1994), Eric Braude define los patrones de diseño como
“combinaciones de componentes, casi siempre clases y objetos que por experiencia se sabe
que resuelven ciertos problemas de diseño comunes” (Braude, 2003). En términos generales
es posible decir que un patrón de diseño es una solución a un problema recurrente en el
diseño de software.
Clasificación de los patrones GoF
Los patrones GoF se clasifican en 3 grandes grupos, según el propósito para el que serán
usados. Los 3 tipos de patrones GoF son:
Patrones de creación
Tratan de la inicialización y configuración de clases y objetos.
Patrones estructurales
Tratan de desacoplar interfaz e implementación de clases y objetos.
Patrones de comportamiento
Tratan de las interacciones dinámicas entre sociedades de clases y objetos.
Patrones de creación.
Abstract Factory
Proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin
especificar sus clases concretas.
Builder
Separa la construcción de un objeto complejo de su representación, de forma que el
mismo proceso de construcción pueda crear diferentes representaciones.
Factory Method
Define una interfaz para crear un objeto, pero deja que sean las subclases quienes
decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de
objetos.
Prototype
Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear
nuevos objetos copiando este prototipo.
Singleton
Garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global
a ella.
Patrones estructurales.
Adapter
Convierte la interfaz de una clase en otra distinta que es la que esperan los clientes.
Permiten que cooperen clases que de otra manera no podrían por tener interfaces
incompatibles.
Bridge
Desvincula una abstracción de su implementación, de manera que ambas puedan variar de
forma independiente.
Composite
Combina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite
que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.
Decorator
Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una
alternativa flexible a la herencia para extender la funcionalidad.
Facade
Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema.
Define una interfaz de alto nivel que hace que el subsistema sea más fácil de usar.
Flyweight
Usa el compartimiento para permitir un gran número de objetos de grano fino de forma
eficiente.
Proxy
Proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.
Patrones de comportamiento.
Chain of Responsibility
Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la
posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa la
petición a través de la cadena hasta que esta sea tratada por algún objeto.
Command
Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con
distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la
operaciones.
Interpreter
Dado un lenguaje, define una representación de su gramática junto con un intérprete que
usa dicha representación para interpretar las sentencias del lenguaje.
Iterator
Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado
sin exponer su representación interna.
Mediator
Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un
bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite
variar la interacción entre ellos de forma independiente.
Memento
Representa y externaliza el estado interno de un objeto sin violar la encapsulación, de
forma que éste puede volver a dicho estado más tarde.
Observer
Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto
cambia de estado se notifica y actualizan automáticamente todos los objetos.
State
Permite que un objeto modifique su comportamiento cada vez que cambia su estado
interno. Parecerá que cambia la clase del objeto.
Strategy
Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables.
Permite que un algoritmo varíe independientemente de los clientes que lo usan.
Template Method
Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos
de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su
estructura.
Visitor
Representa una operación sobre los elementos de una estructura de objetos. Permite
definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.
Referencias
Design Patterns”. Gamma, Helm, Johnson, Vlissides. 1995
[Link]
[Link]
[Link]
_of_Four_en_el_contexto_de_Procesos_de_Desarrollo_de_Aplicaciones_Orientadas_a
_la_Web
Apéndice
El objetivo principal de los patrones es facilitar la reutilización de diseños y
arquitecturas software que han tenido éxito capturando la experiencia y haciéndola accesible
a los no expertos.
El proceso de identificación de patrones de diseño GOF en procesos de desarrollo
software requiere de un conjunto de actividades; inicialmente se construye un conjunto de
criterios que permita establecer un punto de análisis para identificar los procesos de
desarrollo más representativos, siendo obligatorio cumplir estos criterios para catalogarlos
como válidos en este análisis, y obtener la muestra de procesos de desarrollo. El
cumplimiento de las condiciones que deben presentar los procesos de desarrollo es estricto e
importante, puesto que el objetivo de este trabajo de investigación consiste en obtener
resultados a partir del estudio de procesos de desarrollo formales, de esta manera, se
selecciona un grupo de procesos de desarrollo que cumplan con un estricto control de calidad
en las fases de requerimientos, diseño, desarrollo e implantación.
