Patrones Gof

Unidad Docente de Ingeniera del Software
Facultad de informtica - Universidad Politcnica de Madrid
ndice
ACCIN / COMMAND.....................................................................................................................................1
ADAPTADOR / ADAPTER...............................................................................................................................6
APODERADO / PROXY ...................................................................................................................................7
CADENA DE RESPONSABILIDADES / CHAIN OF RESPONSIBILITY...............................................11
COMPOSICIN / COMPOSITE ...................................................................................................................14
CONSTRUCTOR / BUILDER ........................................................................................................................15
DECORADOR / DECORATOR .....................................................................................................................19
ESTADO / STATE............................................................................................................................................21
ESTRATEGIA / STRATEGY .........................................................................................................................22
FBRICA ABSTRACTA / ABSTRACT FACTORY ...................................................................................25
FACHADA / FACADE.....................................................................................................................................26
INTRPRETE / INTERPRETER...................................................................................................................28
ITERADOR / ITERATOR...............................................................................................................................32
MEDIADOR / MEDIATOR ............................................................................................................................34
MTODO DE FBRICA / FACTORY METHOD.......................................................................................35
MTODO PLANTILLA / TEMPLATE METHOD .....................................................................................37
OBSERVADOR / OBSERVER .......................................................................................................................41
PESO MOSCA / FLYWEIGHT ......................................................................................................................42
PROTOTIPO / PROTOTYPE.........................................................................................................................44
PUENTE / BRIDGE .........................................................................................................................................46
RECUERDO / MEMENTO .............................................................................................................................48
________________________________________________________________________________
-i-
SOLITARIO / SINGLETON ...........................................................................................................................50

VISITANTE / VISITOR...................................................................................................................................53
________________________________________________________________________________
- ii -
Coleccin de patrones
Banda de los Cuatro
ACCIN / COMMAND
Tipo
Comportamiento, a nivel de objetos.
Problema
Uno de los elementos principales de una interfaz grfica de usuario (GUI) son los mens
desplegables. En el interior de un men se encuentran una serie de operaciones,
funciones o facilidades que una aplicacin ofrece con relacin a un tema en concreto
(Archivo, Edicin, Ver, Insertar, Formato, etc...). Las distintas entradas de un men tienen
la caracterstica de que al ser pinchadas con el ratn o al ser seleccionadas mediante
teclado ejecutan una operacin concreta. Un modelo de objetos que represente lo
anterior puede ser el siguiente:
APLICACI
N
Aadir(doc)
MEN
ENTRADA
Aadir(entr)
Seleccionar()
ENTRADA_ABRIR
aplicacin
doc
PedirNombre()
Seleccionar()
DOCUMENTO
nb=PedirNombre();
doc=new Documento(nb);
aplicacin->Aadir(doc);
doc->Abrir();
Abrir()
Cerrar()
Copiar()
El siguiente escenario muestra como interactan los objetos del modelo anterior:
doc:Documento
m:Men
e_a:Entrada_Abrir
ap:Aplicacin
new Entrada_Abrir(e_a)
Aadir(e_a)
new Documento(doc)
Seleccionar()
Aadir(doc)
Abrir()
________________________________________________________________________________
-1-
Banda de los Cuatro
Otro elemento relevante de una GUI hoy en da son las barras de botones, al igual que,
en los comienzos de estas interfaces, tambin lo fueron, con una misin similar, las
combinaciones de teclas. En la mayora de los casos, un botn sirve para ejecutar alguna
de las funciones ms usuales de la aplicacin, por lo cual coincide, en la funcin que
desempea, con alguna entrada de algn men. Al modelo de objetos anterior se le han
aadido en negrita las novedades necesarias para representar las barras de botones:
BARRA
Aadir(bot)
APLICACI
N
Aadir(doc)
MEN
ENTRADA
Aadir(entr)
Seleccionar()
BOTN
Presionar()
ENTRADA_ABRIR
aplicacin
doc
PedirNombre()
Seleccionar()
BOTN_ABRIR
doc
PedirNombre()
Presionar()
DOCUMENTO
nb=PedirNombre();
doc->Abrir();
Abrir()
Cerrar()
Copiar()
aplicacin
nb=PedirNombre();
doc->Abrir();
Para el caso de los botones el escenario es similar:

doc:Documento
b_a:Botn_Abrir
b:Barra
ap:Aplicacin
new Botn_Abrir(b_a)
Aadir(b_a)
new Documento(doc)
Presionar()
Aadir(doc)
Abrir()
El problema de esta solucin es que se duplica la implementacin de la operacin que

ejecutan tanto la entrada de men como el botn. El hecho de que existan dos o ms
alternativas para acceder a una misma funcin de la aplicacin (algo positivo, en principio)
no debe traducirse en redundancia a la hora de implantar dicha funcin (algo negativo, por
el desperdicio de recursos que ello implica).
________________________________________________________________________________
-2-
Banda de los Cuatro
Una solucin que nos permite evitar esa redundancia consiste en definir la accin que se
quiere ejecutar como un objeto, al cual pueden referirse todos aquellos elementos grficos
que lo deseen. Aplicando esta idea tenemos la siguiente estructura:
APLICACI
N
Aadir(doc)
MEN
ENTRADA
Aadir(entr)
AsignarAcc()
Seleccionar()
accin
accin
BARRA
Aadir(bot)
ACCIN
Ejecutar()
accin->Ejecutar()
ABRIR
aplicacin
doc
DOCUMENTO
Abrir()
Cerrar()
Copiar()
BOTN
PedirNombre()
Ejecutar()
nb=PedirNombre();
doc->Abrir();
AsignarAcc()
Presionar()
accin->Ejecutar()
Los escenarios siguientes representan, respectivamente, la creacin y posterior

asignacin de una nueva accin a una entrada de men y un botn, as como la ejecucin
de dicha accin mediante la seleccin de ambos elementos grficos:
bot:Botn
accin:Abrir
ent:Entrada
ap:Aplicacin
new Abrir(accin)
AsignarAcc(accin)
AsignarAcc(accin)
doc:Documento
Seleccionar()
ent:Entrada
accin:Abrir
ap:Aplicacin
Ejecutar()
new Documento(doc)
Aadir(doc)
Abrir()
doc:Documento
Presionar()
bot:Botn
accin:Abrir
ap:Aplicacin
Ejecutar()
new Documento(doc)
Aadir(doc)
Abrir()
Solucin
________________________________________________________________________________
-3-
Banda de los Cuatro
Encapsular en un objeto la accin que satisface una peticin.

Contexto
La solucin anterior es apropiada cuando lo fundamental en la relacin entre una
peticin y la accin que la satisface es la FLEXIBILIDAD. Este patrn, al encapsular en
un objeto la accin, promueve una separacin entre dicha accin y la peticin que
resuelve, lo cual redunda en una mayor flexibilidad en todo lo relativo a la accin. Esto
tiene las siguientes consecuencias:
Diferentes objetos pueden ejecutar la misma accin sin necesidad de repetir su
declaracin e implementacin. Basta con que la compartan1.
Se puede cambiar con facilidad (incluso dinmicamente) la accin que realiza o
est asociada a un objeto.
Se pueden aadir nuevas acciones sin tocar las clases ya existentes2.
Se puede especificar, encolar y ejecutar una accin en momentos diferentes3.
Se puede contemplar la posibilidad de deshacer una operacin. Para ello es
necesario disponer de una lista de histricos en la que se reflejen los diferentes estados
por los que pasa el sistema o el objeto afectado por las sucesivas operaciones. Igual que
se deshacen una o varias operaciones, se puede dar la posibilidad de volver a hacer
(rehacer) operaciones ya deshechas.
Se pueden ensamblar acciones, para formar una accin compuesta
(macroaccin). Esto puede resultar interesante en sistemas de informacin que dan
soporte a transacciones4.
Estructura
PETICIONARIO
accin
ACCIN
AsignarAccin()
AtenderPeticin()
Ejecutar()
accin->Ejecutar()
RECEPTOR
receptor
Operacin()
ACCIN CONCRETA
Ejecutar()
receptor -> Operacin()
estado
CLIENTE
Relacionado con
Composicin puede usarse para implementar macroacciones, es decir, Acciones
compuestas.
No se trata de compartir un objeto concreto, sino una clase, a travs de instancias distintas de la misma.
Al representar las acciones como objetos de pleno derecho se da la posibilidad de modificarlas y/o
extenderlas, como al resto de los objetos, aplicando los mecanismos que para ello ofrece la teora de objetos.
3
Como se ha separado la peticin de la accin que la satisface, es posible que tengan un tiempo de vida
distinto, es decir, unas historias no necesariamente paralelas.
4
Una transaccin encapsula una serie de cambios efectuados sobre unos datos. Este patrn sirve muy bien a
este inters, porque permite estructurar el sistema en base a acciones de alto nivel, que se constituyen a partir de
operaciones primitivas.
________________________________________________________________________________
-4-
Banda de los Cuatro
Recuerdo puede usarse para guardar el estado del sistema antes de que una
peticin sea atendida y as poder luego deshacer el efecto de la Accin ejecutada.
Una Accin de la que necesariamente debe hacerse copia antes de ser
introducida en la lista de histricos se comporta como un Prototipo.
Otros aspectos de inters
El Cliente es el responsable de crear la AccinConcreta correspondiente a una
peticin y de configurarla con el Receptor que sabe resolverla.
Accin suele ser una clase abstracta que define la interfaz para la ejecucin de
operaciones.
Para dar soporte a operaciones que se puedan deshacer y/o rehacer es preciso
almacenar la informacin de estado que permita hacerlo y si adems se pretende hacer
esto en mltiples niveles habr que mantener una lista de histricos con las acciones ya
ejecutadas.
Cada AccinConcreta establece una relacin entre el receptor de la peticin y la
accin que ste realiza para satisfacerla.
Para permitir deshacer y/o rehacer operaciones, el estado debe contener
informacin relativa a los receptores, las acciones y las operaciones involucradas en el
proceso.
Las habilidades de cada AccinConcreta van desde la simple invocacin de la
correspondiente Operacin del Receptor hasta la implementacin interna de toda la
accin que satisface la peticin.
________________________________________________________________________________
-5-
Banda de los Cuatro
ADAPTADOR / ADAPTER
Tipo
Estructura, tanto a nivel de clases como a nivel de objetos.
Propsito
Convertir la interfaz de una clase para que se adapte a lo que el cliente que la usa
necesita, permitiendo as que trabajen juntas clases cuyas interfaces son incompatibles.
Estructura
A nivel de clases ...
CLIENTE
OBJETIVO
CLASE A ADAPTAR
Peticin()
PeticinConcreta()
ADAPTADOR
Peticin()
PeticinConcreta()
A nivel de objetos ...
CLIENTE
OBJETIVO
CLASE A ADAPTAR
Peticin()
PeticinConcreta()
ADAPTADOR
Peticin()
adaptado
adaptado->PeticinConcreta()
Cuando usarlo
Cuando se quiere usar una clase ya existente, pero su interfaz no encaja con lo
que se necesita.
Cuando se quiere crear una clase reutilizable, para cooperar con otras clases que
no tengan, necesaria ni previsiblemente, interfaces compatibles.
(slo en la versin para objetos) Cuando se quieren usar varias subclases ya
existentes, pero no resulta prctico adaptarlas una a una mediante herencia. En vez de
esto, se puede adaptar la interfaz de la clase de la cual todas ellas heredan (y
especializan) su comportamiento.
Ventajas
________________________________________________________________________________
-6-
Banda de los Cuatro
Facilidad para redefinir el comportamiento de la clase adaptada.

Simplicidad (un slo objeto, no hay punteros ni indirecciones adicionales).
Flexibilidad para que un slo adaptador trabaje con muchas clases a adaptar (en
concreto, puede hacerlo con toda una jerarqua de clases).
Extensibilidad, puesto que se pueden aadir funcionalidades a todas las clases
adaptadas a la vez.
Inconvenientes
Inflexibilidad, puesto que un slo adaptador no puede trabajar con una clase y sus
hijos a la vez.
Dificultad para redefinir el comportamiento de la clase adaptada.
Relacionado con
Puente tiene una estructura similar pese a ser su objetivo diferente (separar
interfaz de implementacin).
Decorador es ms transparente dado que mejora un objeto sin cambiar su
interfaz.
Apoderado define un delegado para un objeto sin tocar tampoco su interfaz.
En el adaptador a nivel de clase, adaptador hereda pblicamente la interfaz de
objetivo y privadamente la implementacin de la clase a adaptar.
Un adaptador enchufable es una clase que tiene ya definidas internamente las
posibles adaptaciones de su interfaz.
Los adaptadores de doble sentido sirven para obtener transparencia ante
diferentes clientes.
El adaptador a nivel de objeto requiere un poco ms de esfuerzo que el
adaptador a nivel de clase, pero, a la larga, resulta ms flexible!
Ejemplo de aplicacin
En un editor grfico de figuras lo fundamental es tener una abstraccin que
represente la forma de cualquier elemento grfico genrico. Para conformar elementos ya
existentes, nuevos o excesivamente complejos con la interfaz definida para esta forma
genrica podemos usar un adaptador (en este caso, a nivel de objetos).
EDITOR GRAFICO
FORMA
VISTA DE UN TEXTO
Contorno()
ObtenerExtensin()
FORMA DE
FORMA DE TEXTO
LNEA
Contorno()
Contorno()
APODERADO / PROXY
texto
texto -> ObtenerExtensin()
Tipo
________________________________________________________________________________
-7-
Banda de los Cuatro
Estructura, a nivel de objetos.

Propsito
Proporcionar un representante o delegado que se encargue de controlar el acceso
a un objeto, generalmente por motivos de eficiencia.
Estructura
ELEMENTO
CLIENTE
Peticin()
ELEMENTO REAL
Peticin()
APODERADO
Elemento
Real
Peticin()
ElementoReal -> Peticin()
Cuando usarlo
En cualquier situacin en que sea necesaria una referencia a un objeto ms verstil
y/o sofisticada que un simple puntero. Por ejemplo :
Un apoderado remoto proporciona un representante local para un objeto en un
espacio de direcciones diferente (J.Coplien los llama embajadores).
Un apoderado virtual crea por demanda objetos costosos.
Un apoderado de proteccin restringe, por motivos de seguridad, el acceso a un
objeto.
Una referencia inteligente es una sustitucin por un simple puntero, que
incorpora servicios adicionales como cuenta del n de referencias, carga de objetos
persistentes en memoria cuando estos son referenciados y uso de cerrojos para controlar
el acceso exclusivo a regiones crticas.
Ventajas
Se introduce un nivel de indireccin en el acceso al objeto, que permite al
apoderado remoto ocultar el hecho de que el objeto reside en un espacio de direcciones
distinto, al apoderado virtual realizar optimizaciones como la creacin de objetos por
demanda y al apoderado de proteccin y a las referencias inteligentes realizar tareas
adicionales de vigilancia sobre el objeto al que se accede. No obstante todo esto puede
resultar un inconveniente, por motivos de claridad e inteligibilidad del diseo.
Facilita otra optimizacin, relacionada con la creacin de objetos por demanda : la
tcnica de COPY-ON-WRITE, que slo hace efectiva la copia de un objeto oneroso
cuando el acceso a l es de escritura, no de lectura.
Relacionado con
Adaptador proporciona al objeto que est adaptando una interfaz diferente,
mientras que Apoderado presenta la misma interfaz que su representado. No obstante,
en el caso del apoderado de proteccin se pueden rechazar peticiones que el
representado s puede atender, con lo que, de hecho, se est modificando su interfaz.
________________________________________________________________________________
-8-
Banda de los Cuatro
Decorador puede tener una implementacin similar a la de Apoderado, a pesar de

tener una intencin diferente : aadir algn comportamiento a un objeto, en vez de
controlar el acceso al mismo. Diferentes apoderados varan en el grado de semejanza en
su implementacin con respecto a Decorador.
El Apoderado es el encargado de crear y destruir los Elementos Reales cuando
haga falta.
Si el Apoderado puede tratar con el Elemento Real a travs de una interfaz
abstracta, entonces no es necesario tener una clase Apoderado por cada clase de
Elemento Real. Pero si el Apoderado va a ser instanciado con un Elemento Real
concreto, debe conocer de que clase es.
Para poder representar al Elemento Real, el Apoderado debe tener una interfaz
idntica a la de Elemento.
Una cuestin importante es : cmo hacer referencia al representado antes de
instanciarlo?
Un apoderado remoto debe responsabilizarse de empaquetar y enviar las
peticiones y sus argumentos al objeto real.
Un apoderado virtual puede almacenar informacin adicional relativa al objeto
para posponer el acceso al mismo.
Tanto un apoderado de proteccin como una referencia inteligente comprueban
los permisos de acceso del cliente antes de pasar la peticin al objeto.
En un editor de documentos que permite grficas y dibujos complejos dentro de un
documento se nos plantea el problema de que recuperar todos estos costosos elementos
cada vez que se abre el documento es ineficiente e innecesario, por lo que podemos
definir un representante, que ocupe su lugar, hasta que sea necesario cargarlos.
GRFICO
EDITOR DE
Dibujar()
Guardar()
Cargar()
ObtenerContorno()
DOCUMENTOS
________________________________________________________________________________
IMAGEN
REPRESENTANTE
-9Dibujar()
Guardar()
Cargar()
imagen
Dibujar()
Guardar()
Cargar()
if (imagen == 0)
imagen=CargarImagen(fichero);
imagen -> Dibujar();
Banda de los Cuatro
________________________________________________________________________________
- 10 -
Banda de los Cuatro
CADENA DE RESPONSABILIDADES / CHAIN OF RESPONSIBILITY

Tipo
Propsito
Proporcionar a ms de un objeto la capacidad de atender una peticin, para as
evitar el acoplamiento con el que objeto que hace la peticin. Se forma con estos objetos
una cadena, en la cual cada objeto o satisface la peticin o la pasa al siguiente.
Estructura
RESPONSABLE
CLIENTE
sucesor
AtenderPeticin()
RESPONSABLE CONCRETO 1
RESPONSABLE CONCRETO 2
AtenderPeticin()
AtenderPeticin()
Cuando usarlo
Cuando una peticin puede ser atendida por ms de un objeto y el manejador que
la satisfar no se conoce a priori.
Cuando se quiere trasladar una peticin a un objeto de entre unos cuantos, sin
especificar explcitamente el receptor final.
Cuando el conjunto de objetos que pueden atender una peticin se puede
especificar o modificar dinmicamente.
Ventajas
Se reduce el acoplamiento, puesto que se libera al objeto que hace la peticin de
conocer quien se la atiende. No slo eso, sino que, adems, los miembros de la cadena
no conocen la estructura entera, sino slo su sucesor en la misma.
Mayor flexibilidad, puesto que se puede aadir o modificar la capacidad de
atender una peticin, simplemente haciendo cambios en la cadena de responsabilidades,
dinmicamente (en tiempo de ejecucin).
Inconvenientes
No se garantiza la recepcin y satisfaccin de una peticin, pues puede haber
errores en la configuracin de la cadena o tambin puede ocurrir que ningn elemento de
la cadena sepa atender la peticin.
Relacionado con
Cadena de responsabilidades se usa frecuentemente junto a Composicin, donde
lo normal es que el sucesor de un componente en la cadena sea su ancestro en la
estructura jerrquica recursiva.
________________________________________________________________________________
- 11 -
Banda de los Cuatro
Muchas personas ven Cadena de Responsabilidades como una Estrategia

recursiva o distribuida, donde el segundo encapsula unos algoritmos y el primero el
criterio necesario para seleccionar un algoritmo concreto. Parece ser (se trata de una
cuestin de interpretaciones y, por tanto, abierta) que una Estrategia recursiva es una
Cadena de Responsabilidades, pero no al revs, porque los Responsables de sta
ltima pueden hacer ms cosas aparte de encapsular un algoritmo, que es la nica misin
de la primera.
Todos los Responsables en la cadena comparten una interfaz comn, para
garantizar la transparencia que nos permite evitar el acoplamiento.
El Responsable padre de todos los Responsables Concretos puede,
opcionalmente, implementar el enlace al sucesor, para que no tengan que hacerlo sus
hijos o para ofrecer un mismo tipo de enlace a todos ellos (aunque pueden redefinirlo).
En funcin de las circunstancias, se pueden aprovechar enlaces preexistentes
entre objetos para implementar el enlace al sucesor o se pueden definir otros nuevos.
Puede haber un conjunto fijo e inflexible de peticiones que los Responsables
atienden, lo cual aumenta la sencillez y seguridad del sistema, o se puede permitir una
mayor flexibilidad en el tipo de peticiones mediante PARAMETRIZACIN, siempre y
cuando el cliente y los manejadores se pongan de acuerdo acerca del nmero, tipo y
significado de los parmetros.
En un sistema de ayuda dependiente del contexto para una interfaz grfica de
usuario (GUI) se pretende que el usuario, pulsando el ratn sobre un elemento grfico
cualquiera, pueda obtener informacin de ayuda referente al mismo, siendo sta distinta
segn sea la situacin de ese elemento dentro de la interfaz (no es lo mismo un botn en
una caja de dilogo que en la ventana principal de una aplicacin). As, cada elemento
grfico (un botn, por ejemplo), si puede, debe proporcionar esa informacin de ayuda y si
no, debe pasar la peticin al elemento que define el contexto en el que se encuentra (la
caja de dilogo, por ejemplo), con lo que no se sabe a priori quin atender, finalmente,
la peticin, proporcionando la necesaria informacin de ayuda.
GESTOR DE AYUDA
________________________________________________________________________________
- 12 -
Banda de los Cuatro

contexto
AtenderPeticinDeAyuda()
contexto -> AtenderPeticinDeAyuda()
APLICACIN
ELEMENTO GRFICO
DILOGO
BOTN
MostrarAyuda()
AtenderPeticinDeAyuda()
si puede dar la ayuda

MostrarAyuda();
si no
contexto::AtenderPeticinDeAyuda();
________________________________________________________________________________
- 13 -
Banda de los Cuatro
COMPOSICIN / COMPOSITE
Tipo
Propsito
Permitir a los clientes tratar uniformemente a los objetos simples y compuestos de
una estructura jerrquica recursiva.
Estructura
COMPONENTE
CLIENTE
Operacin()
SIMPLE
COMPUESTO
Operacin()
Operacin()
hijos
para todos los hijos

hijo.Operacin();
Cuando usarlo
Cuando se pretende representar una jerarqua recursiva de objetos.
Cuando se pretende que los clientes no reparen en las diferencias entre objetos
simples y compuestos.
Ventajas
Simplifica notablemente al cliente, al no tener ste que distinguir entre objetos
simples y compuestos.
Favorece la extensibilidad, ya que es muy fcil aadir nuevos tipos de
componentes, tanto simples como compuestos.
Inconvenientes
Puede hacer el diseo peligrosamente genrico, dificultando la imposicin de
restricciones sobre ciertos componentes de la jerarqua (por ejemplo, las comprobaciones
de tipo no se pueden hacer con garanta ms que en tiempo de ejecucin). Esta es la
otra cara de la facilidad para la extensibilidad.
Relacionado con
Es frecuente que la relacin entre un componente y su padre se use para una
Cadena de Responsabilidades.
Decorador es muy frecuentemente usado junto a Composicin, como un hijo ms
del padre comn de la jerarqua (Componente), por lo que debe adaptarse a su interfaz.
________________________________________________________________________________
- 14 -
Banda de los Cuatro
PesoMosca permite la comparticin de componentes, pero presenta problemas a

la hora de hacer referencia a los padres (ambigedad por tener un componente varios
padres).
Iterador se usa para recorrer jerarquas de composicin recursiva.
Visitante localiza operaciones y comportamientos que de otro modo estaran
dispersos entre las clases Simple y Compuesto.
El cliente slo trata con un componente genrico, no pudiendo, por tanto,
distinguir si es simple o compuesto.
Componente puede tener algn mecanismo para acceder al padre en la
jerarqua de cada objeto (necesario para Cadena de Responsabilidades).
Cuanto mayor sea la interfaz de Componente mayor ser la uniformidad
(=transparencia) con la que el cliente trata a los distintos elementos, pero eso tiene el
inconveniente de que un elemento simple hereda operaciones que slo tienen sentido
para elementos compuestos.
Si las operaciones de gestin de los hijos (Poner, Quitar, etc ...) se ponen en
Componente prima la TRANSPARENCIA sobre la SEGURIDAD. Si se ponen en
Compuesto sucede al contrario.
La estructura de datos utilizada para representar a los hijos depende de las
circunstancias de cada caso, siempre en aras de la EFICIENCIA (ver Intrprete).
Si los hijos estn ordenados de alguna forma, el acceso y la gestin de los
mismos debe ser especialmente cuidadosa (ver Iterador). Adems, salvo en lenguajes
con recoleccin de basura, la eliminacin de los hijos es tarea del padre.
Un editor de dibujos permite al usuario construir complejas composiciones a partir
de elementos bsicos, que se ensamblan unos en/con otros. Utilizando el patrn
Composicin podemos usar adecuadamente la composicin recursiva para ocultar al
cliente las diferencias entre elementos grficos sencillos y compuestos.
ELEMENTO GRFICO
Dibujar()
ObtenerHijo(int)
Quitar(Componente)
Aadir(Componente c)
RECTNGULO
LNEA
TEXTO
Dibujar()
Dibujar()
Dibujar()
DIBUJO
Dibujar()
ObtenerHijo(int)
Quitar(Componente)
Aadir(Componente c)
componentes
para todos los componentes
c.Dibujar();
aadir c a la lista de
componentes;
CONSTRUCTOR / BUILDER
________________________________________________________________________________
- 15 -
Tipo
Banda de los Cuatro
Creacin, a nivel de objetos.
Propsito
Separar la construccin y la representacin de un objeto complejo, para as permitir
que el mismo proceso de construccin sirva para crear diferentes representaciones.
Estructura
constructor
DIRECTOR
Construir()
CONSTRUCTOR
ConstruirParte()
para todos los objetos de la estructura

{constructor->ConstruirParte();}
CONSTRUCTOR CONCRETO
ConstruirParte()
ObtenerResultado()
PRODUCTO
Cuando usarlo
Cuando el algoritmo de creacin del objeto complejo debe ser independiente de
qu partes y cmo lo componen.
Cuando el proceso de construccin debe soportar diferentes representaciones
para el objeto que se construye.
Ventajas
El diseo gana en flexibilidad, dado que cambiar la representacin interna del
producto que se construye es tan sencillo como definir un nuevo tipo de constructor.
La separacin (independencia) entre el proceso de construccin y la

representacin del producto fomenta la reutilizacin, puesto que permite que diferentes
directores construyan variantes de un producto a partir del mismo conjunto de partes.
Se favorece el encapsulamiento y el control, puesto que cada constructor concreto
contiene todo el cdigo necesario para crear y ensamblar todas las partes de un producto
y adems el constructor crea el producto paso a paso (parte a parte) bajo la supervisin
del director, que al final recibe el producto completo, de manos del constructor.
Relacionado con
Como constructor de objetos complejos, este patrn es similar a Fbrica
Abstracta. La diferencia reside en que Constructor se centra en la creacin de los objetos
paso a paso (parte a parte), mientras Fbrica Abstracta est orientado a familias de
________________________________________________________________________________
- 16 -
Banda de los Cuatro
objetos (simples o complejos). Adems, en el primero el resultado se obtiene en el ltimo

paso y en el segundo se obtiene inmediatamente.
Las estructuras de los objetos complejos que crea este patrn nos llevan
frecuentemente al patrn Composicin.

Constructor suele ser una clase abstracta, por lo que ConstruirParte es una
operacin abstracta; en concreto, una por cada tipo de parte del objeto complejo. En
C++, suelen ser mtodos vacos, no virtuales puros!
En general no tiene sentido contemplar una clase abstracta de productos, dada la
heterogeneidad de los mismos.
La operacin Construir, por lo general, es una sucesin de peticiones de
construccin de partes, pero, a veces, es necesario acceder a partes de la estructura ya
construidas (o acciones similares).
La funcin ObtenerResultado es de suma importancia, ya que a travs de ella el
Director puede conseguir el producto final, una vez construidas todas sus partes y
ensambladas.
Un proceso que lea documentos en el formato de intercambio RTF (Rich Text
Format) debe ser capaz de convertirlo a otros muchos formatos de texto. El problema es
que el n de los mismos es abierto y desconocido, por lo que debe ser fcil aadir uno
nuevo sin tocar al proceso que lee los documentos en RTF.
________________________________________________________________________________
- 17 -
LECTOR RTF
Banda de los Cuatro

constructor
constructores
CONVERSOR DE TEXTO
TraducirRTF()
while (t = siguiente token)

{
switch t.Tipo
{
CHAR :
constructor->ConvertirCaracter(t.Char);
FUENTE :
constructor->ConvertirCambio
DeFuente(t.Fuente);
PRRAFO :
constructor->ConvertirParrafo();
}
}
ConvertirCarcter(char)
ConvertirCambioDeFuente(fuente)
ConvertirParrafo()
CONVERSOR A ASCII
CONVERSOR A TEX
ObtenerTextoEnAscii()
ConvertirParrafo()
ObtenerTextoEnTEX()
CONVERSOR A ELEMENTOS
GRFICOS DE TEXTO
ConvertirParrafo()
ObtenerElementoGrficoDeTexto()
Texto en Ascii
Elemento Grfico de Texto
Texto en TEX
________________________________________________________________________________
- 18 -
Banda de los Cuatro
DECORADOR / DECORATOR
Tipo
Propsito
Aadir responsabilidades adicionales a un objeto dinmicamente, proporcionando
una alternativa flexible a la especializacin mediante herencia, cuando se trata de aadir
funcionalidades.
Estructura
COMPONENTE
Operacin()
COMPONENTE CONCRETO
DECORADOR
Operacin()
Operacin()
componente
componente -> Operacin;
Decorador::Operacin();
Comportamiento();
DECORADOR CONCRETO A
DECORADOR CONCRETO B
Comportamiento()
Operacin()
Operacin()
EstadoAnidado
Cuando usarlo
Cuando se quiere aadir responsabilidades a un objeto de manera dinmica y
transparente (independientemente de otros objetos).
Cuando es imposible la extensin de funcionalidad por herencia, por ser aquella
imprevisible en tipo y nmero.
Ventajas
Aporta una mayor flexibilidad que la herencia esttica, permitiendo, entre otras
cosas, aadir una funcionalidad dos o ms veces.
Evita concentrar en lo alto de la jerarqua clases guiadas por las
responsabilidades, es decir, que pretenden (en vano) satisfacer todas las posibilidades.
De esta forma las nuevas funcionalidades se componen de piezas simples que se crean y
se combinan con facilidad, independientemente de los objetos cuyo comportamiento
extienden.
Inconvenientes
La transparencia tiene el inconveniente de que, a pesar de ser diferentes por
muchos motivos, un decorador y un componente son indistinguibles, por lo que no se
puede confiar en la identidad de los objetos.
________________________________________________________________________________
- 19 -
Banda de los Cuatro
Gran fragmentacin5; el sistema se llena de gran cantidad de objetos pequeos, lo

cual puede dificultar el aprendizaje de su funcionamiento y su depuracin, aunque el que
lo domine puede adaptarlo fcilmente.
Relacionado con
Adaptador cambia la interfaz de un objeto (ocasionalmente puede tener que
aadir alguna funcionalidad) mientras que Decorador centra su atencin en ampliar las
responsabilidades de un objeto, sin tocar su interfaz.
Decorador puede ser visto como una degeneracin de Composicin con un slo
componente, que adems extiende funcionalidades.
Decorador permite cambiar la piel de un objeto, mientras que Estrategia cambia
sus entraas. Esto hace que frente a la TRANSPARENCIA que da Decorador respecto
a los componentes, Estrategia presenta una interfaz propia e independiente, que no tiene
porque amoldarse a la de los componentes6.
Componente debe permanecer lo ms ligera posible, definiendo una interfaz
genrica y simple, para no arrastrar hacia complejidades innecesarias a Componentes
Concretos y Decoradores (ver Composicin).
Un Decorador puede convertirse en una solucin muy costosa si los componentes
son, por naturaleza, muy complejos. En esos casos es preferible Estrategia.
Puede resultar problemtico especializar mediante herencia los Componentes
Concretos, por culpa de la coherencia que el Decorador debe guardar, en cuanto a
interfaz se refiere, con la clase base (Componente).
En los conjuntos de utilidades para interfaces grficas de usuario (GUI) se puede
permitir aadir a los componentes visuales propiedades (por ejemplo, un borde) o
comportamientos (por ejemplo, una barra de desplazamiento).
COMPONENTE VISUAL
Dibujar()
VISTA DE UN TEXTO
DECORADOR
Dibujar()
Dibujar()
componente
componente -> Dibujar();
Decorador::Dibujar();
DibujarBorde();
5
6
BORDE
BARRA DE DESPLAZAMIENTO
DibujarBorde()
Dibujar()
Dibujar()
DesplazarHasta()
AnchoDelBorde
PosicinDeDesplazamiento
Esta es la esencia del paradigma orientado a objetos, luego no veo porque ha de ser un inconveniente.
Los autores de este catlogo parecen replantearse la bondad de Decorador y se inclinan por Estrategia.
________________________________________________________________________________
- 20 -
Banda de los Cuatro
ESTADO / STATE
Tipo
Propsito
Permitir a un objeto modificar su comportamiento a medida que su estado interno
va cambiando, dando as la impresin de que el objeto cambia de clase.
Estructura
CONTEXTO
estado
ESTADO
Peticin()
estado -> Atender();
Atender()
ESTADO CONCRETO A
ESTADO CONCRETO B
Atender()
Atender()
Cuando usarlo
Cuando el comportamiento de un objeto depende de su estado y debe poder
cambiar dinmicamente (en tiempo de ejecucin) dicho comportamiento, a medida que
cambie dicho estado.
Cuando las operaciones tienen definiciones largas y con mltiples condiciones,
dependientes del estado del objeto, siendo lo ms adecuado separar en objetos
independientes cada condicin atmica, para poder as combinarlas y modificarlas
independientemente, ya sea en estados ya existentes, ya en otros nuevos que se formen
combinndolos.
Ventajas
Dado que el comportamiento especfico de cada estado est autocontenido en
cada estado concreto, existe una gran flexibilidad para aadir nuevos estados y
transiciones, mediante la definicin de nuevas subclases.
A pesar de que la distribucin del comportamiento ante diferentes situaciones
entre diferentes objetos incrementa el n de clases y reduce la compacidad, es la mejor
solucin cuando hay muchos estados, pues evita las definiciones multicondicionales y
grandes, tan indeseables como los procedimientos gigantes lo son en el estilo imperativo.
Se hacen ms explcitas las transiciones entre estados que s todo estuviera
concentrado en una sola clase (esto hace ms inteligible el diseo), impidiendo adems
los estados internos inconsistentes (desde el punto de vista del contexto, los cambios de
estado son ATMICOS).
Si los objetos que representan los estados no tienen variables de instancia (esto
es, el estado est totalmente definido en su propio tipo) entonces diferentes contextos
pueden compartir estados, como PesoMosca sin estado intrnseco, slo comportamiento.
Relacionado con
________________________________________________________________________________
- 21 -
Banda de los Cuatro
PesoMosca explica como los objetos Estado pueden ser compartidos.

Los objetos Estado a menudo son Solitarios.
La misin de Contexto es definir la interfaz que interesa a los clientes, mientras
mantiene una referencia al Estado actual. Si dicho Estado necesita tener acceso al
Contexto al que est asociado, ste puede pasarse a si mismo como parmetro de la
peticin.
Si los estados que van a hacer falta no se conocen a priori y el Contexto
cambia de Estado poco frecuentemente, es mejor ir creando/destruyendo estados sobre
la marcha. Pero si el Contexto cambia constantemente de Estado es preferible crear
todos los estados al comienzo y no destruirlos nunca (pueden volver a hacer falta).
Las transiciones entre estados pueden estar prefijadas a priori en el Contexto o
pueden dejarse a la responsabilidad de cada estado, que tendr entonces que saber
quien le sucede (aparte de este inconveniente, esta solucin es ms flexible y, por ello,
preferible). Otra alternativa es una transicin entre estados definida tabularmente. Esto
permite cambiar el criterio de transicin cambiando solamente los datos de entrada, pero
es menos eficiente, hace menos explcitas las transiciones entre estados y dificulta el
aadir acciones a dichas transiciones7.
Algunos lenguajes (Self) permiten a un objeto cambiar de clase en tiempo de
ejecucin, en lo que constituye una especie de herencia dinmica; esto es, soportan
directamente este patrn.
Para cualquier protocolo de comunicaciones el comportamiento que manifiesta
depende directamente del estado en que se encuentre : conectado, escuchando, cerrado,
etc...
CONEXIN_TCP
estado
ESTADO_TCP
Abrir()
Cerrar()
MandarConfirmacin()
Abrir()
Cerrar()
MandarConfirmacin()
estado -> Abrir();
TCP_CONECTADO
TCP_ESCUCHANDO
TCP_CERRADO
Abrir()
Cerrar()
MandarConfirmacin()
Abrir()
Cerrar()
MandarConfirmacin()
Abrir()
Cerrar()
MandarConfirmacin()
ESTRATEGIA / STRATEGY
Estado centra su atencin en el comportamiento dependiente del estado y la aproximacin basada en tablas
en las transiciones entre estados!
________________________________________________________________________________
- 22 -
Tipo
Banda de los Cuatro
Propsito
Definir una familia de algoritmos encapsulando por separado cada uno de ellos y
hacindolos, por tanto, intercambiables. Esto permite a los algoritmos variar con
independencia de los clientes que los usan.
Estructura
CONTEXTO
estrategia
ESTRATEGIA
InterfazDelContexto()
estrategia -> InterfazDelAlgoritmo();
InterfazDelAlgoritmo()
ESTRATEGIA CONCRETA A
ESTRATEGIA CONCRETO B
Cuando usarlo
Cuando muchas clases relacionadas slo se diferencian en su comportamiento.
Cuando se necesitan diferentes variantes de un algoritmo.
Cuando un algoritmo usa datos que los clientes no tienen porque conocer.
Cuando una clase define muchos comportamientos, los cuales se manifiestan
como definiciones condicionales mltiples de sus operaciones.
Ventajas
Las familias jerrquicas de estrategias definen algoritmos y comportamientos que
enfatizan la reutilizacin. La herencia puede ayudar a sacar factor comn a la
funcionalidad de los algoritmos.
El encapsulamiento de algoritmos en clases separadas ofrece una ventajosa
alternativa a la especializacin por herencia del contexto para obtener un comportamiento
diferente, que promueve la independencia, la facilidad de entender el diseo y la
posibilidad de futuras extensiones.
Se eliminan las costosas definiciones de comportamiento multicondicionales.
Se posibilita ofrecer diferentes implementaciones del mismo comportamiento, en
funcin de restricciones como el espacio en memoria o el tiempo de respuesta.
Inconvenientes
Los clientes deben tener un cierto conocimiento de cada estrategia, para as
poder elegir en cada situacin cual es la ms apropiada.
Dado que todas las estrategias comportan una interfaz comn, si las diferencias
entre ellas es grande, es probable que mucha de la informacin que se les pasa no sea
de utilidad ms que a las ms complejas.
Puede producirse una gran explosin en el nmero de objetos del sistema. Esto
se puede aliviar si las estrategias se implementan como objetos sin estado que los
contextos pueden compartir (ver PesoMosca).
________________________________________________________________________________
- 23 -
Banda de los Cuatro
Relacionado con
Los objetos Estrategia a menudo son buenos PesosMosca.
Si el Contexto pasa a la Estrategia los datos como parmetros de las
operaciones de esta ltima se mantiene un acoplamiento dbil, pero la eficiencia se puede
resentir (puede que haya Estrategias que reciban datos que no necesitan). Si el
Contexto se pasa a s mismo como parmetro o la Estrategia mantiene una referencia
al Contexto se resuelve este ltimo problema a cambio de un mayor acoplamiento.
Los clientes configuran al Contexto con una Estrategia determinada, con la
cual el Contexto interacta para producir un comportamiento determinado. Para tal fin,
el Contexto puede definir una interfaz que permita a la Estrategia acceder a sus datos
internos.
Existe la posibilidad de que el Contexto defina un comportamiento por defecto y
slo en el caso de que los clientes deseen otra cosa se le configure con la Estrategia
correspondiente.
En C++, en el caso de que la Estrategia se fije en tiempo de compilacin y se
vaya a cambiar en ejecucin se pueden usar plantillas (templates) para configurar un
Contexto con una Estrategia.
En un editor de texto pueden existir mltiples algoritmos para dividir un documento
en lineas (algoritmo simple, algoritmo TEX, algoritmo matricial, etc ...), siendo deseable
que la complejidad de los mismos quede oculta al cliente y que sea fcil y cmodo el
cambio sobre la marcha de uno por otro o la adicin de nuevos algoritmos al sistema.
algoritmo
DOCUMENTO
Recorrer()
Repaginar()
ALGORITMO
algoritmo -> DividirEnLineas();
DividirEnLineas()
ALGORITMO TEX
ALGORITMO SIMPLE
ALGORITMO MATRICIAL
DividirEnLineas()
DividirEnLineas()
DividirEnLineas()
________________________________________________________________________________
- 24 -
Banda de los Cuatro
FBRICA ABSTRACTA / ABSTRACT FACTORY

Tipo
Propsito
Proporcionar una interfaz para la creacin de familias de objetos interdependientes
o interrelacionados, sin especificar sus clases concretas.
Estructura
PRODUCTO
ABSTRACTO A
PRODUCTO-A2
PRODUCTO
ABSTRACTO B
CLIENTE
PRODUCTO-B2
PRODUCTO-A1
PRODUCTO-B1
FABRICA ABSTRACTA
CrearProductoA()
CrearProductoB()
FABRICA CONCRETA 1
FABRICA CONCRETA 2
CrearProductoA()
CrearProductoB()
CrearProductoA()
CrearProductoB()
Cuando usarlo
Cuando el sistema debe ser independiente de como sus productos se crean,
componen y representan.
Cuando el sistema debe configurarse con una familia de productos de entre
mltiples posibles.
Cuando se quiere dar nfasis a la restriccin de que una familia de productos ha
sido diseada para que acten todos juntos.
Cuando se quiere proporcionar una librera de clases de productos, de los que
slo se desea revelar su interfaz, no su implementacin.
Ventajas
________________________________________________________________________________
- 25 -
Banda de los Cuatro
Se potencia el encapsulamiento, puesto que se asla a los clientes de las

implementaciones.
Se incrementa la flexibilidad del diseo, resultando fcil cambiar de familia de
productos (recordemos que acta toda junta).
Se refuerza la consistencia, puesto que se restringe el uso a productos de una
sola familia cada vez.
Inconvenientes
Se dificulta la extensibilidad, puesto que no es fcil aadir nuevos tipos de
productos8.
Relacionado con
La implementacin de las clases contenidas en este patrn lleva, usualmente, a
otros dos patrones : Mtodo de Fbrica y Prototipo.
Como lo ms usual es que slo necesitemos una fbrica concreta por familia de
productos, esto nos allega al patrn Solitario.
FbricaAbstracta no suele ser una clase abstracta en realidad, sino que,
generalmente, proporciona una implementacin bsica o estndar de las operaciones,
que ser redefinida a voluntad por sus subclases.
En el diseo de una interfaz de usuario que d soporte a mltiples estndares de
presentacin, como Motif o Presentation Manager, los diferentes estndares de
presentacin definen diferentes aspectos y comportamientos en elementos grficos de la
interfaz de usuario, tales como : barras de desplazamiento, ventanas o botones.
CLIENTE
VENTANA
VENTANA MOTIF
VENTANA PM
BARRA DE DESPLAZAMIENTO
BARRA MOTIF
BARRA PM
FABRICA DE ELEMENTOS GRFICOS

CrearBarraDeDesplazamiento()
CrearVentana()
FABRICA DE ELEMENTOS PM
FABRICA DE ELEMENTOS MOTIF
CrearVentana()
CrearVentana()
FACHADA / FACADE
8
Existe un conflicto, ya clsico, entre la extensibilidad y la flexibilidad.
________________________________________________________________________________
- 26 -
Tipo
Banda de los Cuatro
Propsito
Proporcionar una interfaz unificada de alto nivel que, representando a todo un
subsistema, facilite su uso. La fachada satisface a la mayora de los clientes, sin ocultar
las funciones de menor nivel a aquellos que necesiten acceder a ellas.
Estructura
Cliente2
Cliente1
Cliente3
Cliente2
Cliente1
Cliente3
FACHADA
Clase1 del
subsistema
Clase2 del
subsistema
Clase1 del
subsistema
Clase4 del
subsistema
Clase3 del
subsistema
Clase5 del
subsistema
Clase2 del
subsistema
Clase4 del
subsistema
Clase3 del
subsistema
Clase5 del
subsistema
SUBSISTEMA
DE CLASES
SUBSISTEMA
DE CLASES
Cuando usarlo
Cuando se pretende proporcionar una interfaz simple para un subsistema
complejo.
Cuando existen muchas dependencias entre los clientes y las clases que
implementan una abstraccin. Una fachada proporciona al subsistema independencia y
portabilidad.
Cuando se pretende estructurar en capas el subsistema (cada capa tendr su
propia fachada).
Ventajas
Al separar al cliente de los componentes del subsistema, se reduce el nmero de
objetos con los que el cliente trata, facilitando as el uso del subsistema.
Se promueve un acoplamiento dbil entre el subsistema y sus clientes,
eliminndose o reducindose las dependencias.
No existen obstculos para que las aplicaciones usen las clases del subsistema
que necesiten. De esta forma podemos elegir entre facilidad de uso y generalidad.
Relacionado con
________________________________________________________________________________
- 27 -
Banda de los Cuatro
Fbrica Abstracta puede usarse conjuntamente con Fachada para proporcionar

una interfaz que permita crear objetos del subsistema de manera independiente a ste.
Adems, puede ser una alternativa para ocultar las clases especficas de una plataforma.
Mediador es similar a Fachada pues tambin abstrae la funcionalidad de clases ya
existentes, pero est orientado a la comunicacin entre objetos colegas y adems suele
centralizar aquellas responsabilidades que no competen a ninguno de ellos. Por su parte,
como hemos visto, Fachada abstrae la interfaz de un subsistema para facilitar su uso, sin
aadir funcionalidades y resultando transparente a ste.
Lo ms frecuente es que slo haya un objeto Fachada de cada tipo. De ah su
relacin con Solitario.
La Fachada sabe qu clase es responsable de cada peticin, pero es
completamente transparente para ellas. Por tanto, aunque las funciones las desempean
las otras clases, es a la Fachada a quien le toca el trabajo de traducir.
Una manera de reducir el acoplamiento es hacer abstracta la Fachada y luego
especializar mediante herencia. Otra posibilidad es configurar la Fachada con objetos
del subsistema, que pueden cambiarse. Esta posibilidad puede entrar en conflicto con el
objetivo de la Fachada, la facilidad de uso.
Un subsistema es anlogo a una clase, en el sentido de que tiene una interfaz
PBLICA (de la que forma parte la Fachada) y otra PRIVADA (que no est muy claro
como conseguirla ni para que sirve!).
En un entorno de programacin se permite a las aplicaciones el acceso al
subsistema de compilacin. Este subsistema contiene clases como el AnalizadorLxico,
el AnalizadorSintctico, el AnalizadorSemntico, el GeneradorDeCdigoIntermedio o el
GeneradorDeCdigoFinal. No obstante slo aplicaciones muy especiales necesitan
acceder directamente a algunas de estas clases, mientras que para el resto se puede
definir una interfaz general, una fachada, que les permita sencillamente compilar sus
programas.
COMPILADOR
CLASES DEL SUBSISTEMA DE
COMPILACIN
Compilar()
Cadena
AnalizadorLxico
Token
Smbolo
AnalizadorSintctico
CadenaEnCdigoBit
ConstructorDeNodosDePrograma
GeneradorDeCdigo
NodoDePrograma
NodoDeDefinicin
NodoDeVariable
GeneradorDeCdigo para
una Mquina de Pila
GeneradorDeCdigo para
una Mquina RISC
NodoDeExpresin
INTRPRETE / INTERPRETER
________________________________________________________________________________
- 28 -
Tipo
Banda de los Cuatro
Comportamiento, a nivel de clases.
Propsito
Dado un lenguaje, define una representacin para su gramtica junto con un
intrprete que usa dicha representacin para interpretar sentencias en ese lenguaje.
Estructura
CLIENTE
EXPRESIN ABSTRACTA
Interpretar(contexto)
CONTEXTO
EXPRESIN TERMINAL
EXPRESIN NO TERMINAL
Cuando usarlo
Principalmente, cuando haya un lenguaje que interpretar y sus diferentes
construcciones puedan representarse mediante rboles sintcticos abstractos. Da sus
mejores resultados cuando la gramtica es simple (con gramticas complejas la jerarqua
de clases se hace inmanejable y es mejor usar generadores automticos de analizadores
sintcticos) y la eficiencia no es una cuestin vital (existen formas ms eficientes de
interpretar, usando mquinas de estado finitas en lugar de rboles sintcticos).
Ventajas
Facilidad para cambiar o extender la gramtica, mediante herencia, dado que las
diferentes reglas de la gramtica se representan con clases.
Facilidad para implementar la gramtica, dado que las implementaciones de las
clases nodo del rbol sintctico son similares, pudiendo usarse para ello generadores
automticos de cdigo.
Facilidad para introducir nuevas formas de interpretar las expresiones en la
gramtica (tener en cuenta el patrn Visitante).
Inconvenientes
Limitacin en el tipo de gramticas (y, por extensin, de problemas) para los que
sirve esta aproximacin : simples y sin grandes necesidades de eficiencia. Aunque el uso
de otros patrones puede mitigar este problema, hay circunstancias en que un Intrprete
no es lo ms apropiado.
Relacionado con
Considerado en su forma ms general (una operacin distribuida sobre una
jerarqua de clases basada en el patrn Composicin), prcticamente toda aparicin de
ste lleva unida la de un Intrprete. Pero es una cuestin de perspectiva (subjetiva!) la
que nos lleva a plantearnos un Intrprete slo cuando la jerarqua de clases (rbol
sintctico) define un lenguaje.
________________________________________________________________________________
- 29 -
Banda de los Cuatro
PesoMosca ofrece una forma de compartir los smbolos terminales del rbol
sintctico.
El Intrprete puede usar un Iterador para recorrer la estructura.
Visitante puede servir para mantener el comportamiento de cada nodo del rbol
sintctico abstracto en una sola clase.
Si un tipo particular de problemas se presenta frecuentemente, puede ser
provechoso expresar los diferentes casos del problema como sentencias de un lenguaje
simple.
Se puede, entonces, construir un intrprete que resuelva el problema
interpretando dichas sentencias.
Si es frecuente la creacin de nuevos intrpretes o de nuevas formas de
interpretar es mejor tener un Visitante, donde poner la operacin a realizar fuera de la
estructura de rbol.
El Cliente construye (o recibe) una estructura de instancias de Expresiones
terminales y Expresiones no terminales, ensambladas para formar un rbol sintctico
que representa la sentencia que se quiere interpretar, mientras que el Contexto contiene
informacin global para el intrprete.
A pesar de la similitud de la estructura de este patrn con la del patrn
Composicin hay sus diferencias, como que al Intrprete no le interesa como se construye
el rbol sintctico (eso es cosa del Cliente o de quien sea).
Aunque la operacin estrella es Interpretar, un Intrprete puede ser utilizado
para realizar otra serie de operaciones sobre las sentencias de un lenguaje.
El problema de encontrar palabras que encajen en un patrn se puede resolver
definiendo un lenguaje para ello, por ejemplo mediante Expresiones Regulares. Esto
nos permite ya aplicar un Intrprete a dicho lenguaje para resolver el problema :
expresin :: = literal | alternativa | secuencia | repeticin

literal :: = a | b | c | ... {a | b | c | ... } *
alternativa :: = expresin | expresin
secuencia :: = expresin & expresin
repeticin :: = expresin *
________________________________________________________________________________
EXPRESIN REGULAR
repeticin
- 30 -
Interpretar()
expresin2
expresin1
Banda de los Cuatro
________________________________________________________________________________
- 31 -
Banda de los Cuatro
ITERADOR / ITERATOR
Tipo
Propsito
Proporcionar una forma de acceder secuencialmente a los elementos de un objeto
compuesto por agregacin sin necesidad de desvelar su representacin interna.
Estructura
AGREGADO
CrearIterador()
ITERADOR
CLIENTE
Primero()
Siguiente()
Actual()
AGREGADO CONCRETO
ITERADOR CONCRETO
CrearIterador()
Primero()
Siguiente()
Actual()
return new IteradorConcreto(this);
Cuando usarlo
Cuando se quiere acceder a los elementos de un objeto agregado sin mostrar su
representacin interna.
Cuando se quieren permitir recorridos mltiples en objetos agregados.
Cuando se quiere proporcionar una interfaz uniforme para recorrer diferentes
estructuras de agregacin (iteracin polimrfica9).
Ventajas
Se incrementa la flexibilidad, dado que para permitir nuevas formas de recorrer
una estructura basta con modificar el iterador en uso, cambiarlo por otro
(parametrizacin!) o definir uno nuevo.
Se enfatiza la distribucin de responsabilidades (y, por ello, la simplicidad de los
elementos del sistema), dado que la interfaz del agregado se ve libre de una serie de
operaciones, ms propias de la interfaz del iterador.
Se facilitan el paralelismo y la concurrencia, puesto que, como cada iterador tiene
consciencia de su estado en cada momento, es posible que dos o ms iteradores recorran
una misma estructura simultnea o solapadamente.
Relacionado con
Iterador se aplica a menudo a estructuras recursivas del tipo de Composicin.
Los Iteradores polimrficos se basan en Mtodo de Fbrica a la hora de instanciar
el tipo de iterador apropiado a cada caso.
Usar slo en caso de necesidad.
________________________________________________________________________________
- 32 -
Banda de los Cuatro
Tambin es habitual que Iterador use un Recuerdo para capturar el estado de una
iteracin, de forma interna.
Cuando el Cliente controla la iteracin se dice que el Iterador es externo y
cuando la controla el propio Iterador se dice que es interno. Los Iteradores externos
son ms flexibles y potentes, mientras que los internos son ms sencillos de usar. Los
Iteradores externos son problemticos con estructuras recursivas como las de
Composicin (se suelen usar entonces Iteradores Nulos).
Si el algoritmo para recorrer la estructura lo proporciona el agregado, el Iterador
slo guarda el estado y se le llama CURSOR (ver Recuerdo). Si el algoritmo reside en el
propio Iterador es ms fcil usar el mismo sobre estructuras diferentes o diferentes
algoritmos sobre la misma estructura, puede violarse el encapsulamiento, por necesidad
de acceder a variables privadas de la estructura.
Dada la estrecha relacin entre el Agregado y el Iterador ste puede ser una
clase amiga de aquel, sin necesidad de sobrecargar la interfaz de dicho Agregado.
Un Iterador robusto no debe verse afectado por altas y bajas en los elementos
de estructura que recorre ni necesitar hacer una copia de la misma cada vez que sta se
modifica (que los cambios se reflejen en el estado del Iterador!).
Cada AgregadoConcreto es el encargado de crear el Iterador Concreto que se
adapta a su estructura concreta (ver Mtodo de Fbrica).
Una lista es un objeto agregado que puede beneficiarse de un Iterador que lo
recorra sin exponer su estructura interna, permitiendo as diferentes tipos de listas (listas
normales, listas de tipo skip10, ...) y diferentes tipos de iteradores.
LISTA ABSTRACTA
CrearIterador()
Contar()
Aadir(elemento)
Eliminar(elemento)
...
ITERADOR
CLIENTE
LISTA NORMAL
Primero()
Siguiente()
Actual()
SeLlegoAlFinal()
ITERADOR NORMAL
LISTA SKIP
ITERADOR SKIP
10
Una lista skip es una estructura de datos probabilstica de caractersticas similares a los rboles
balanceados.
________________________________________________________________________________
- 33 -
Banda de los Cuatro
MEDIADOR / MEDIATOR
Tipo
Propsito
El diseo OO enfatiza la distribucin de responsabilidades entre objetos. Tal
distribucin puede devenir en una estructura con muchas conexiones entre objetos (en el
peor caso, todos con todos). Aunque la distribucin favorece la REUTILIZACIN, la
proliferacin de relaciones entre objetos puede ser un grave obstculo. Por ello, este
patrn define un objeto que encapsula la forma en que interactan un grupo de objetos,
promoviendo as un acoplamiento dbil al evitar las referencias explcitas entre los objetos
y permitiendo, por tanto, que su interaccin se modifique de forma independiente.
Estructura
MEDIADOR
MEDIADOR
CONCRETO
mediador
COLABORADOR
COLABORADOR
CONCRETO 1
COLABORADOR
CONCRETO 2
Cuando usarlo
Cuando existe un conjunto de objetos cuya comunicacin est bien definida pero
es compleja, con lo que las interdependencias que surgen estn poco estructuradas y son
difciles de entender.
Cuando reutilizar un objeto se ve dificultado por la cantidad de referencias que
tiene a otros objetos.
Cuando un comportamiento distribuido entre varias clases debe ser adaptable a
las circunstancias, sin tener que abusar de la especializacin por herencia.
Ventajas
Se limita el uso de la herencia, al concentrar en el Mediador un comportamiento
que, de otro modo, estara distribuido entre diversos objetos.
Modificar este
comportamiento puede requerir especializar el Mediador, pero ya no afectar a los
objetos que interactan.
Al reducir el acoplamiento entre los objetos que interactan es ms fcil variar o
reutilizar dichos objetos y el Mediador, independientemente.
Se simplifican los protocolos de comunicacin entre los objetos, al sustituir las
relaciones muchos-a-muchos por relaciones uno-a-muchos, que son ms sencillas de
entender, mantener y extender.
Al hacer de la mediacin un concepto independiente, encapsulado en un objeto
aparte, se favorece el centrar la atencin en la interaccin entre objetos, al margen del
comportamiento individual de cada uno.
Inconvenientes
________________________________________________________________________________
- 34 -
Banda de los Cuatro
Se cambia complejidad en la interaccin por complejidad en el Mediador, que se

puede convertir en el elemento ms complejo del conjunto de objetos. Este carcter
monoltico lo har difcil de mantener11.
Relacionado con
La diferencia entre Mediador y Fachada es que el protocolo del primero es
multidireccional, mientras que el del segundo es slo unidireccional (de la Fachada hacia
los elementos del subsistema).
Los Colaboradores pueden comunicarse con el Mediador usando el patrn
Observador.
Si los Colaboradores slo trabajan con un MediadorConcreto, entonces el
Mediador abstracto y general sobra, pues es el propsito del acoplamiento abstracto que
con l se plantea es, precisamente, permitir trabajar con varios Mediadores diferentes.
Una posibilidad para implementar los MediadoresConcretos es usar el patrn
Observador; otra, definir en el Mediador una interfaz de notificacin especializada, que
permita al objeto identificarse cuando se comunica con el Mediador.
Cuanto ms compleja sea la estructura de objetos que pone en comunicacin el
Mediador, menores sern los beneficios que podr proporcionar.
En una Interfaz Grfica de Usuario (GUI) hay, entre otras cosas, elementos como
los cuadros de dilogo, que contienen, dentro de una ventana, una serie de elementos
grficos (botones, mens, campos de entrada de datos, etc ...) para permitir al usuario
una interaccin rpida y fcil con el sistema. Las interrelaciones entre dichos elementos
grficos contenidos en un cuadro de dilogo son a la vez tan complejas y variables (son
diferentes en cada cuadro y an dentro del mismo, segn las circunstancias) que la
utilizacin de un Mediador para controlar y coordinar dichas relaciones es muy til.
director
DIRECTOR DE DILOGO
ELEMENTO GRFICO
Cambiado()
MostrarDilogo()
CrearElementosGrficos()
ElementoCambiado(elem)
DIRECTOR DE DILOGO
BASICO
botn
BOTN
Activar()
Desactivar()
CrearElementosGrficos()
ElementoCambiado(elem)
director->ElementoCambiado(this);
CAMPO DE ENTRADA
DE DATOS
IntroducirTexto()
campo
MTODO DE FBRICA / FACTORY METHOD

Tipo
Creacin, a nivel de clases.

11
Todos los inconvenientes de cualquier sistema centralizado son vlidos tambin en este caso.
________________________________________________________________________________
- 35 -
Banda de los Cuatro
Propsito
Definir una interfaz para la creacin de un objeto, pero permitiendo a las subclases
decidir de que clase instanciarlo. Permite, por tanto, que una clase difiera la instanciacin
en favor de sus subclases.
Estructura
CREADOR
PRODUCTO
PRODUCTO CONCRETO
MtodoFbrica()
UnaOperacin()
producto = MtodoFbrica();
CREADOR CONCRETO
MtodoFbrica()
return new ProductoConcreto();
Cuando usarlo
Cuando una clase no puede adelantar las clases de objetos que debe crear.
Cuando una clase pretende que sus subclases especifiquen los objetos que ella
crea.
Cuando una clase delega su responsabilidad hacia una de entre varias subclases
auxiliares y queremos tener localizada a la subclase delegada.
Ventajas
Se gana en flexibilidad, pues crear los objetos dentro de una clase con un
Mtodo de Fbrica es siempre ms flexible que hacerlo directamente, debido a que se
elimina la necesidad de atar nuestra aplicacin unas clases de productos concretos.
Se facilitan futuras ampliaciones, puesto que se ofrece las subclases la posibilidad
de proporcionar una versin extendida de un objeto, con slo aplicar en los Productos la
misma idea del Mtodo de Fbrica.
Se facilita, en cuanto a que se hace natural, la conexin entre jerarquas de clases
paralelas, que son aquellas que se generan cuando una clase delega algunas de sus
responsabilidades en una clase aparte. Ambas jerarquas de clases paralelas son
creadas por un mismo cliente y el patrn Mtodo de Fbrica establece la relacin entre
parejas de subclases concretas en las mismas.
Inconvenientes
Se obliga al cliente a definir subclases de la clase Creador slo para crear un
producto concreto y esto puede no ser apropiado siempre12.
12
Se resuelve parametrizando o usando las plantillas de C++ (templates).
________________________________________________________________________________
- 36 -
Banda de los Cuatro
Relacionado con
Fbrica Abstracta es frecuentemente implementado con Mtodo de Fbrica.
Mtodo de Fbrica habitualmente se utiliza dentro de Mtodo Plantilla.
Prototipo no requiere hacer subclases de Creador, pero s una operacin de
Inicializar en la clase Producto, que no le hace falta a Mtodo de Fbrica.
MtodoFbrica puede ser algo ms que una mera declaracin del mtodo,
puede tener una implementacin genrica, por defecto. En C++, es un mtodo virtual,
generalmente puro.
Parametrizando MtodoFbrica con el tipo del producto a crear nos ahorramos
las subclases de Creador (tambin se pueden usar templates, en C++).
La filosofa que sigue el Creador es de INICIALIZACIN PEREZOSA, ya que, al
acceder al producto, si no existe todava, se crea.
En un marco de referencia para aplicaciones que pueden presentar mltiples
documentos al usuario, no se sabe, a priori, los tipos de documentos con los que va a
trabajar cada aplicacin concreta. El marco de referencia debe, por tanto, instanciar
clases, pero slo tiene conocimiento de las clases abstractas, las cuales no pueden ser
instanciadas. La solucin est en hacer que CrearDocumento() sea un Mtodo de Fbrica que
se encargue de la fabricacin del objeto oportuno en cada situacin (es una operacin
abstracta en la clase abstracta , pero concreta y distinta en las subclases
correspondientes a cada tipo de aplicacin.
DOCUMENTO
Abrir()
Cerrar()
Guardar()
VoverAtrs()
DOCUMENTO GRFICO
docs
APLICACIN
CrearDocumento()
AbrirDocumento()
NuevoDocumento()
Documento *doc = CrearDocumento();

docs.Aadir(doc);
doc -> Abrir();
APLICACIN GRFICA
CrearDocumento()
return new DocumentoGrfico;
MTODO PLANTILLA / TEMPLATE METHOD

Tipo
Comportamiento, a nivel de clases.
Propsito
________________________________________________________________________________
- 37 -
Banda de los Cuatro
Definir el esqueleto de un algoritmo para una operacin, dejando para sus

subclases la capacidad de redefinir el funcionamiento de los pasos de este algoritmo,
siempre y cuando la estructura del mismo permanezca intacta.
Estructura
CLASE ABSTRACTA
OperacinPrimitiva1();
OperacinPrimitiva2();
OperacinPrimitiva1()
MtodoPlantilla()
CLASE CONCRETA
Cuando usarlo
Cuando se pretende implementar una sola vez las partes invariantes de un
algoritmo, permitiendo a las subclases implementar el comportamiento que puede variar.
Cuando se quiere sacar factor comn del comportamiento compartido por varias
clases para localizarlo en un nica clase, que evita la duplicacin de cdigo. A esta
tcnica se la conoce comnmente como REFACTORIZAR PARA GENERALIZAR y sigue
el esquema :
+ Identificar las diferencias en el cdigo ya existente.
+ Separarlas, convirtindolas en operaciones nuevas.
+ Reemplazar las diferencias en el cdigo existente por un MtodoPlantilla
que invoque a las operaciones que necesite.
Cuando se quieren controlar las extensiones de las subclases, definiendo
MtodosPlantilla que invocan operaciones adaptables (la clase abstracta da una
implementacin por defecto, que suele ser vaca, pero las subclases pueden redefinirla),
que son las que permiten extender el comportamiento.
Ventajas
Los MetodosPlantilla son una tcnica fundamental para reutilizar cdigo,
especialmente en las libreras de clases, donde son la razn de ser de la factorizacin de
comportamiento comn. Llevan a una estructura de control invertido, cuyo paradigma es
el Principio de Hollywood : <<NO NOS LLAME, YA LE LLAMAREMOS>>, esto es, la
clase padre invoca la implementacin que la clase hija hace de operaciones primitivas,
pero no al revs.
Relacionado con
Los Mtodos de Fbrica estn entre las operaciones a las que ms
frecuentemente invoca un Mtodo Plantilla, junto con operaciones concretas (tanto de la
clase abstracta como de la clase concreta), las operaciones primitivas abstractas y las
operaciones adaptables.
________________________________________________________________________________
- 38 -
Banda de los Cuatro
La diferencia entre Mtodo Plantilla y Estrategia es que el primero usa la herencia

para variar parte de un algoritmo mientras el segundo usa la delegacin para variar
completamente un algoritmo.
La ClaseAbstracta define el MtodoPlantilla (que define un algoritmo en
trminos de operaciones abstractas) mientras que la ClaseConcreta implementa las
OperacionesPrimitivas (esto es, redefine las operaciones abstractas en sus homnimas
concretas) que dotan al algoritmo de un comportamiento concreto.
Para que no pueda ser redefinido, el MtodoPlantilla, en C++, puede hacerse
funcin miembro virtual.
Si se quiere que las OperacionesPrimitivas slo puedan ser invocadas por el
MtodoPlantilla se pueden definir como miembros protegidos. Adems hay que
distinguir entre operaciones adaptables (pueden redefinirse) y operaciones abstractas
(deben redefinirse), ya que estas ltimas deben hacerse virtuales puras.
La ClaseAbstracta define el orden de las operaciones primitivas, pero deja a las
ClasesConcretas la posibilidad de redefinir su funcionamiento.
Una forma de identificar ms fcilmente las operaciones que deben poderse
redefinir es anteponerles un prefijo decidido a priori y que se aclaratorio : por ejemplo,
Hacer-.
Un objetivo primordial es reducir al mnimo el nmero de operaciones primitivas
que hay que redefinir.
En un marco de referencia para aplicaciones y documentos, las aplicaciones son
las responsables de abrir los documentos almacenados en un formato externo al sistema
(un fichero, por ejemplo), mientras que los documentos representan y dan formato a la
informacin, una vez sta es leda del fichero. Dado que este marco de referencia
puede usarse para muchos tipos de aplicaciones y documentos, se pueden definir
Mtodos Plantilla (por ejemplo, NuevoDocumento()) que definan los algoritmos que satisfacen
las operaciones genricas, mientras las subclases aportan el conocimiento preciso para
dotarlos de un comportamiento concreto.
DOCUMENTO
Abrir()
Cerrar()
Guardar()
Hacer-Leer()
docs
APLICACIN
Hacer-CrearDocumento()
AbrirDocumento()
NuevoDocumento()
Documento *doc = Hacer-CrearDocumento();

docs.Aadir(doc);
doc -> Abrir();
________________________________________________________________________________
APLICACIN GRFICA
DOCUMENTO GRFICO
- 39 Hacer-CrearDocumento()
return new DocumentoGrfico;
Banda de los Cuatro
Hacer-Leer()
________________________________________________________________________________
- 40 -
Banda de los Cuatro
OBSERVADOR / OBSERVER
Tipo
Propsito
Un efecto lateral muy frecuente en aquellos sistemas que se fragmentan en un
conjunto de clases que cooperan es la necesidad de mantener la consistencia entre los
distintos objetos interrelacionados. Para no recurrir a soluciones fuertemente acopladas
(que reducen la posibilidad de reutilizacin), este patrn define una dependencia uno-amuchos entre objetos, para que, cuando uno de ellos cambie su estado, todos los que
dependan de l sean avisados y puedan actualizarse convenientemente.
Estructura
ASUNTO
Ligar(Observador)
Desligar(Observador)
Notificar()
ASUNTO CONCRETO
FijarEstado()
ObtenerEstado()
observadores
OBSERVADOR
Actualizar()
para todo observador

{Actualizar()}
asunto
EstadoDelObservador =
asunto -> ObtenerEstado();
return EstadoDelAsunto;
OBSERVADOR
CONCRETO
Actualizar()
EstadoDelObservador
EstadoDelAsunto
Cuando usarlo
Cuando una abstraccin presenta dos aspectos, un dependiente del otro.
Encapsular estos aspectos en objetos separados nos permite variar y reutilizarlos
independientemente.
Cuando un cambio en un objeto requiere cambiar otros objetos y no sabemos
cuntos exactamente lo necesitarn.
Cuando un objeto debe poder notificar sus cambios a otros objetos, sin necesidad
de saber nada acerca de su identidad (acoplamiento dbil).
Ventajas
Dado que el Asunto no conoce la clase de Observadores que tiene, el
acoplamiento que existe es mnimo y abstracto. Por ello, tanto unos como otros pueden
variar y evolucionar en diferentes niveles de detalle de forma independiente.
Se facilita y simplifica el radiado de las notificaciones. El Asunto slo tiene que
comunicar los cambios; luego, cada Observador es libre para hacer o no caso. Esto
permite gran libertad a la hora de dar de alta o baja a los Observadores.
Inconvenientes
Dado el desconocimiento que unos Observadores tienen de los otros, cualquier
operacin aparentemente inofensiva puede originar una cascada de costosas
actualizaciones. Adems, sin un protocolo preciso, en el que se especifique lo que
cambia, el esfuerzo se multiplica.
________________________________________________________________________________
- 41 -
Banda de los Cuatro
Relacionado con
Un Gestor de Cambios que encapsula la semntica de actualizaciones en las
relaciones complejas entre Asuntos y Observadores acta como Mediador.
Un Gestor de Cambios puede usar el patrn Solitario para hacerse nico y
globalmente accesible.
La forma ms simple de implementar las relaciones entre Asuntos y
Observadores es mantener referencias explcitas y directas, lo cual puede resultar
prohibitivo. Otra opcin es utilizar una tabla hash que tiene el inconveniente de
complicar el acceso. Cuando la relacin entre Asuntos y Observadores es compleja se
puede definir un Gestor de Cambios (ver Mediador) que mantiene las referencias entre
unos y otros, define una poltica de actualizaciones coherente y la pone en prctica con
cada cambio en un Asunto que lo requiera.
Hay que asegurarse de que las operaciones que cursan notificaciones lo hacen
una vez que el estado es consistente despus del cambio, nunca antes (ver Mtodo
Plantilla), luego LA NOTIFICACIN DEBE SER SIEMPRE LO LTIMO.
Aunque es frecuente que sea un Observador el que origina el cambio en el
Asunto, dicho Observador se suele esperar hasta que llega la notificacin del Asunto
para actualizar su propio estado. Si se contempla la posibilidad de observar a ms de un
Asunto, Actualizar debe parametrizarse para saber a cual se refiere el cambio.
Si la Notificacin corre a cargo del propio Asunto se simplifica la tarea al
cliente, pero puede ser ineficiente (muchas actualizaciones). La opcin contraria, permite
juntar en una sola varias actualizaciones, pero complica la tarea del cliente.
Para evitar las referencias colgadas cuando un Asunto desaparece, ste debe
notificarlo a sus Observadores para que estos puedan inutilizar sus referencias. La
notificacin puede ser muy detallada (modelo PUSH) o un simple aviso, que el
Observador completa pidiendo la informacin que le interese (modelo PULL).
Para mejorar la eficiencia, el Asunto puede tener constancia de ciertos
Observadores interesados en ciertos eventos, avisndolos slo a ellos cuando ocurren.
Algunos lenguajes (Smalltalk) no permiten herencia mltiple y favorecen la unin
de Asuntos y Observadores, en lugar de separarlos en clases y objetos diferentes.
Un RelojDigital y un RelojAnalgico observan como cambia el estado de un
Temporizador y se actualizan de acuerdo con dichos cambios de estado.
ASUNTO
observadores
OBSERVADOR
Notificar()
TEMPORIZADOR
Actualizar()
asunto
RELOJ ANALGICO
RELOJ DIGITAL
Actualizar()
Actualizar()
PulsoDeReloj()
asunto
PESO MOSCA / FLYWEIGHT
________________________________________________________________________________
- 42 -
Tipo
Banda de los Cuatro
Propsito
Mejorar la eficiencia a la hora de mantener una gran cantidad de objetos de grano
fino, usando la idea de la comparticin. Un PesoMosca es un objeto compartido que
puede ser usado en diferentes contextos simultneamente, de forma transparente,
indistinguible. El concepto clave aqu es la distincin entre el ESTADO INTRNSECO
(informacin independiente del contexto del objeto, almacenada en el mismo y que
favorece su comparticin) y el ESTADO EXTRNSECO (informacin que depende y vara
con el contexto donde se use el objeto, no puede ser compartida y se la proporciona el
cliente que lo usa, a travs de la fbrica) del objeto compartido.
Estructura
FBRICA DE PESOS MOSCA
PesosMosca
PESOMOSCA
ObtenerPesoMosca(clave)
Si existe PesoMosca(clave)
return PesoMoscaExistente;
en otro caso {crearlo;
aadirlo al grupo;
return PesoMoscaNuevo;}
Operacin(EstadoExtrnseco)
PESOMOSCA CONCRETO
PESOMOSCA CONCRETO
NO COMPARTIBLE
EstadoIntrnseco
EstadoCompleto
CLIENTE
Cuando usarlo
Cuando sea cierto que :
La aplicacin usa un gran nmero de objetos.
Los costes de almacenamiento son prohibitivos como consecuencia de lo anterior.
La mayor parte del estado del objeto puede considerarse extrnseco.
Muchos grupos de objetos pueden reemplazarse por unos pocos objetos
compartidos una vez que se ha prescindido del estado extrnseco.
La aplicacin no depende de la identidad de los objetos, difuminada como
consecuencia de la comparticin de los mismos.
Ventajas
Mejora en la eficiencia, sobre todo en relacin con el ahorro en el
almacenamiento, que aumenta paralelamente con la comparticin de objetos y es funcin
de :
(a) la reduccin en el n total de instancias.
(b) la cantidad de estado intrnseco por objeto.
(c) si el estado extrnseco es computado (calculado) o almacenado.
Inconvenientes
Se introducen costes en tiempo de ejecucin asociados a las transferencias,
bsquedas y/o computacin del estado extrnseco (y su almacenamiento).
________________________________________________________________________________
- 43 -
Banda de los Cuatro
Relacionado con
PesoMosca se combina habitualmente con Composicin para implementar
estructuras jerrquicas lgicas en trminos de grafos acclicos dirigidos con nodos hoja
compartidos. Como consecuencia de la comparticin un nodo hoja no puede tener un
puntero a su padre (ambigedad, pues tiene varios), si no que ste se le pasa como parte
del estado extrnseco.
Suele ser muy ventajoso implementar Estado y Estrategia como PesosMosca.
Eliminar el EstadoExtrnseco de los objetos compartidos puede no reducir los
costes de almacenamiento si resultan ser tan variados como los propios objetos.
La FbricaDePesosMosca es quien gestiona y controla las clases compartibles,
permitiendo a los clientes el acceso (indirecto) a las mismas. Suele usar almacenamiento
asociativo para facilitar a los clientes el acceso a los objetos compartidos de su inters (si
el n de stos es grande y/o variable se pueden necesitar tcnicas de cuenta de
referencias o recoleccin de basura para eliminarlos y recuperar el espacio ocupado).
Los PesosMoscaConcretosNoCompartibles en una jerarqua recursiva pueden
tener hijos que s sean para compartir. Adems tenerlos inmersos en dicha jerarqua
recursiva, junto a los que si se comparten, puede facilitar en el futuro hacerlos tambin a
ellos compartibles, si se considera oportuno o necesario.
El Cliente proporciona a las clases compartibles el EstadoExtrnseco que les
falta, pero siempre a travs de la FbricaDePesosMosca, NUNCA DIRECTAMENTE.
En un editor de documentos podemos tener una jerarqua recursiva de elementos
grficos, tales como filas, columnas, caracteres, etc ... algunos de los cuales tendr
sentido hacer compartibles, por motivos de eficiencia. Tal es el caso de los caracteres. Si
por cada carcter del documento creamos un objeto los problemas de almacenamiento
aparecern de inmediato, mientras que stos se resolvern fcilmente si slo se crea un
objeto por cada tipo distinto de carcter (256, en ASCII), compartible por cada aparicin
de los mismos en el texto, en diferentes posiciones (este sera su estado extrnseco).
ELEMENTO GRFICO
Dibujar(Contexto)
Intersectar(Punto,Contexto)
hijos
FILA
CARCTER
COLUMNA
Dibujar(Contexto)
Dibujar(Contexto)
Dibujar(Contexto)
hijos
char c
PROTOTIPO / PROTOTYPE
Tipo
Propsito
________________________________________________________________________________
- 44 -
Banda de los Cuatro
Especificar los tipos de objetos que queremos crear usando una instancia
prototpica y crear nuevos objetos copiando dicho prototipo.
Estructura
CLIENTE
prototipo
PROTOTIPO
Operacin()
p = prototipo->Clonar();
return
(copia de si mismo);
Clonar()
PROTOTIPO
PROTOTIPO
CONCRETO 1
Clonar()
CONCRETO 2
Clonar()
return
Cuando usarlo
Cuando el sistema debe ser independiente de como se crean, componen y
representan sus productos .... (y)
Cuando las clases a instanciar se especifican en tiempo real o se quiere evitar
construir una jerarqua de fbricas paralela a la de productos o las instancias de una clase
pueden tomar una de entre unas pocas combinaciones distintas de estado.
Ventajas
Potencia el encapsulamiento, ya que, al igual que Fbrica Abstracta y Constructor,
oculta al cliente las clases de productos concretos con los que trabaja.
Dota al sistema de una mayor flexibilidad, pues se pueden aadir/eliminar
productos concretos dinmicamente13.
Se pueden definir nuevos tipos de objetos instanciando clases ya existentes y
registrando estas instancias como nuevos prototipos para el cliente. Por tanto, se pueden
definir nuevas clases SIN PROGRAMAR NADA.
Se reduce drsticamente la especializacin mediante herencia, lo cual siempre
ayuda a la reutilizacin. En C++, esto es especialmente til puesto que no hay
metaclases, con lo cual las clases no son objetos de primer orden y tampoco hay
informacin de tipos en tiempo de ejecucin.
Permite configurar una aplicacin en tiempo de ejecucin (aadir/eliminar clases
dinmicamente).
Inconvenientes
Cada subclase de Prototipo debe implementar la operacin Clonar y esto
puede resultar difcil en clases que ya existen o que incluyen objetos que no admiten la
copia o que contienen referencias circulares.
Relacionado con
Prototipo y Fbrica Abstracta son patrones rivales en muchos sentidos, aunque
tambin pueden trabajar juntos, cooperando.
13
En esto es superior a los otros patrones de creacin.
________________________________________________________________________________
- 45 -
Banda de los Cuatro
Aquellos diseos que hacen un uso muy acentuado de los patrones Composicin
y Decorador frecuentemente pueden beneficiarse tambin del patrn Prototipo.
La operacin Clonar puede ser conflictiva, pues el constructor que se utilice para
hacer la copia debe asegurar la independencia total con respecto al original (esto incluye
el no compartir estructuras, por ejemplo).
Prototipo puede requerir una operacin para inicializar.
Para hacer un editor de msica podemos adaptar un marco de referencia para
editores grficos en general, aadiendo las clases de elementos grficos que necesitemos
como las notas, los silencios o el pentagrama. El problema surge cuando, como
frecuentemente ocurre, dicho marco de referencia proporciona una paleta de
herramientas para manipular los elementos grficos (aadir, seleccionar, mover, etc ...),
puesto que dichas herramientas, al no conocer estas clases especficas de elementos
grficos, no saben como crearlos. La solucin est en hacer que las herramientas creen
cualquier elemento grfico mediante copia o clonacin de una instancia de una subclase
de la clase abstracta y general que representa dichos elementos grficos. Dicha instancia
recibe el nombre de prototipo.
prototipo
HERRAMIENTA
Manipular()
ELEMENTO GRFICO
Dibujar(posicin)
Clonar()
HERRAMIENTA GRFICA
PENTAGRAMA
NOTA
PENTAGRAMA
Manipular()
Dibujar(posicin)
Clonar()
Dibujar(posicin)
Clonar()
Dibujar(posicin)
Clonar()
return
return
return
p = prototipo->Clonar();
while (usuario mueva el ratn)
p->Dibujar (nueva_posicin);
insertar p en el dibujo;
PUENTE / BRIDGE
Tipo
Propsito
Separar una abstraccin de su implementacin para permitir que ambos puedan
variar independientemente.
________________________________________________________________________________
- 46 -
Banda de los Cuatro
Estructura
ABSTRACCIN
imp
Operacin()
ABSTRACCIN
REFINADA
imp->Implementacin();
IMPLEMENTACIN
CLIENTE
Implementacin()
IMPLEMENTACIN
IMPLEMENTACIN
CONCRETA 1
Implementacin()
CONCRETA 2
Implementacin()
Cuando usarlo
Cuando se quiere evitar una unin permanente entre abstraccin e
implementacin.
Cuando se quiere extender tanto abstraccin como implementacin por herencia.
Cuando se quiere evitar que posibles cambios en la implementacin de una
abstraccin afecten a los clientes.
Cuando se quiere ocultar la implementacin de la vista de los clientes.
Cuando se tiene que hacer frente a una proliferacin de clases tal que el uso de la
herencia no es recomendable por su inflexibilidad.
Cuando se quiere tener muchos objetos compartiendo una misma implementacin
de manera transparente al cliente (se usan mecanismos de cuenta de referencias).
Ventajas
La separacin entre interfaz e implementacin permite configurar (y cambiar) esta
relacin dinmicamente, en tiempo de ejecucin (y no de compilacin). Adems, esta
independencia favorece una mejor estructuracin en niveles del sistema.
La citada independencia de variacin repercute en una mayor extensibilidad.
Se favorece el encapsulamiento, al ocultarse a los clientes detalles referentes a la
implementacin, como la comparticin de implementaciones, por ejemplo.
Relacionado con
Fbrica Abstracta puede servir para crear y configurar un Puente en concreto.
Adaptador trabaja con sistemas ya diseados, tratando de hacer compatibles
clases con diferentes interfaces, mientras que Puente realiza su misin durante la fase de
diseo, posibilitando que abstracciones e implementaciones varen independientemente.
Al contrario que Adaptador, Puente no puede construirse usando herencia mltiple
(pblica para la interfaz y privada para la implementacin) porque esto ligara de forma
permanente una implementacin a una abstraccin (al menos en C++, que tiene herencia
esttica).
Abstraccin puede conocer todas las ImplementacionesConcretas y elegir una
o puede tener una por defecto o puede delegar la decisin en una Fbrica Abstracta.
Si slo hay una implementacin, la clase base de la jerarqua de
implementaciones puede no ser necesaria, pero la separacin entre abstraccin e
implementacin s, porque garantiza la independencia.
________________________________________________________________________________
- 47 -
Banda de los Cuatro
En una Interfaz Grfica de Usuario (GUI) lo normal es tratar de permitir que los
distintos elementos grficos (una ventana, por ejemplo) se adapten a los diferentes
contextos en que deben ser usados y a las diferentes plataformas hardware sobre las que
pueden funcionar. As, no ser lo mismo una ventana en el sistema Xwindows que en el
sistema Presentation Manager (PM). Y siempre podemos querer especializar el elemento
grfico genrico (la ventana) para adecuarnos mejor a ciertas circunstancias concretas
(no es lo mismo una ventana para albergar iconos que una ventana temporal, para
acontecimientos transitorios como una ayuda en lnea o una solicitud de introduccin de
datos por el usuario). Por tanto, puede ser de mucha utilidad (sobre todo pensando en
futuras ampliaciones) separar los aspectos de interfaz de los de implementacin.
puente
imp
VENTANA
IMPLEMENTACIN DE
VENTANA
DibujarTexto()
DibujarCuadro()
VENTANA PARA
ICONOS
DibujarBorde()
ImplementaDibujarTexto()
ImplementaDibujarLinea()
imp->ImplementaDibujarLinea();
DibujarCuadro();
DibujarTexto();
IMPLEMENTACIN DE
IMPLEMENTACIN DE
VENTANA XWINDOW
VENTANA PM
XDibujarTexto();
XDibujarLinea();
RECUERDO / MEMENTO
Tipo
Propsito
Capturar y exteriorizar el estado interno de un objeto, sin violar el encapsulamiento,
para que dicho objeto pueda restaurar este estado en el futuro, si lo desea.
Estructura
recuerdo
CUIDADOR
ORIGINADOR
RECUERDO
________________________________________________________________________________
- 48 -
FijarRecuerdo(Recuerdo r)
CrearRecuerdo()
estado
Banda de los Cuatro
ObtenerEstado()
FijarEstado()
estado
estado = r -> ObtenerEstado();
return new Recuerdo(estado);
Cuando usarlo
Cuando sea necesario registrar una instantnea (o parte de ella) del estado
interno de un objeto para permitir posteriores restauraciones de dicho estado registrado y,
adems, exista el peligro de que una interfaz directa, abierta sobre el propio objeto,
pueda exponer detalles de implementacin del mismo, rompiendo as el encapsulamiento.
Ventajas
Se salvaguarda el encapsulamiento, impidiendo la exposicin pblica de
informacin que slo el Originador debe manejar, pero que, por otra parte, puede (y
debe) almacenarse fuera del mismo.
Se simplifica al objeto Originador, que en otros diseos posibles, que tambin
preservaran el encapsulamiento, tendra que hacerse cargo del mantenimiento de todas
las versiones del estado interno en que los clientes estuvieran interesados.
Inconvenientes
El uso de Recuerdos puede convertirse en inapropiado, por el excesivo consumo
de recursos, en el caso de que la informacin que el Originador deba almacenar en el
Recuerdo sea considerable o las peticiones de los clientes solicitando Recuerdos sea
demasiado frecuente.
Puede resultar problemtico en ciertos lenguajes el mantenimiento de dos
interfaces distintas (amplia para el Originador y estrecha para el Cuidador) para
acceder al Recuerdo.
Puede haber costes ocultos en el cuidado de los Recuerdos, pues los
Cuidadores son los responsables de eliminar los Recuerdos que vigilan, pese a no
conocer sus interioridades, lo cual dificulta su labor.
Relacionado con
Accin puede usar Recuerdo para mantener el estado en aquellas operaciones
que se pueden deshacer (cambios de estado incrementales).
Iterador puede ser sustituido o implementado en trminos de Recuerdo, dado que
una interfaz para iteraciones basada en Recuerdos permite que ms de una iteracin se
haga simultnea o solapadamente (cosa que ya permite Iterador) y adems no rompe el
encapsulamiento de la coleccin que se recorre (el Recuerdo slo es interpretada por la
propia coleccin de objetos que se recorre, nadie ms tiene acceso a ella).
El Recuerdo tiene dos interfaces distintas : el Cuidador ve una interfaz
estrecha que slo le permite pasar el Recuerdo a otros objetos y el Originador ve una
interfaz amplia que le permite acceder a los datos necesarios y hacer todas las
manipulaciones necesarias para restaurar un estado almacenado.
________________________________________________________________________________
- 49 -
Banda de los Cuatro
Slo el Originador puede meter y sacar informacin en el Recuerdo, que

resulta, por tanto, opaco (caja negra) para el resto de los objetos.
Cuando los Recuerdos se crean y se retrotraen en un orden prefijado, entonces
se puede almacenar slo el cambio incremental que cada uno hace sobre el estado del
anterior (ver Accin) y las operaciones con posibilidad de deshacer/rehacer.
La misin del Recuerdo es simplemente la de ser un objeto que guarde una
instantnea del estado interno del objeto que lo invoca (el Originador), mientras que el
Cuidador es el responsable de la custodia segura del Recuerdo.
En un editor grfico podemos tener elementos como cajas o recuadros que se
pueden conectar entre si por medio de flechas o lineas discontinuas. Existe la posibilidad
de mover de posicin todo (o partes de) un dibujo, siendo requisito indispensable que las
relaciones entre los distintos elementos del mismo se mantengan, a pesar de variar su
situacin en el documento. Ms an es deseable que un traslado de elementos de un
dibujo pueda ser deshecho fcilmente y con total eficiencia, esto es, que todo quede como
al principio. Por lo general, las relaciones espaciales entre estos elementos se mantienen
y resuelven con un sistema de resolucin de restricciones, que puede almacenar en un
objeto aparte su estado en un momento determinado, para poder as restaurarlo cuando
la operacin que lo sac de l sea deshecha o anulada por el usuario.
ESTADO DEL RESOLUTOR
RESOLUTOR DE
RESTRICCIONES
EDITOR
sol
ObtenerEstado()
FijarEstado()
estado
FijarRecuerdo(Recuerdo r)
CrearRecuerdo()
recuerdo
HacerMover()
DeshacerMover()
estado
return new Recuerdo(estado);
estado = r -> ObtenerEstado();
recuerdo = sol -> CrearRecuerdo();

sol -> Mover(+posicin);
sol -> ResolverRestricciones();
sol -> Mover(-posicin);
sol -> FijarRecuerdo(recuerdo);
sol -> ResolverRestricciones();
SOLITARIO / SINGLETON
Tipo
Propsito
Garantizar que una clase slo tiene una nica instancia, proporcionando un punto
de acceso global a la misma.
Estructura
SOLITARIO
return Instancianica;
static Instancia()
OperacinDelSolitario()
ObtenerDatosDelSolitario()
________________________________________________________________________________
- 50 -
Banda de los Cuatro
static Instancianica
DatosDelSolitario
Cuando usarlo
Cuando debe haber nicamente una instancia de una clase y debe ser claro su
acceso para los clientes.
Cuando la Instancianica debe ser especializable mediante herencia y los
clientes deben poder usar la instancia extendida sin modificar su cdigo (el de los
clientes).
Ventajas
El acceso a la Instancianica est ms controlado.
Se reduce el espacio de nombres (frente al uso de variables globales).
Permite refinamientos en las operaciones y en la representacin, mediante la
especializacin por herencia de Solitario.
Es fcilmente modificable para permitir ms de una instancia y, en general, para
controlar el nmero de las mismas (incluso si es variable).
Es ms flexible que la alternativa de las operaciones de clase, adems de que
stas (en C++), al ser funciones miembro estticas, no son virtuales, luego no pueden ser
especializadas mediante herencia ni redefinidas polimrficamente.
Relacionado con
Muchos otros patrones pueden implementarse haciendo uso de Solitario. Por
ejemplo : Fbrica Abstracta, Constructor y Prototipo.
El mtodo Instancia es el punto de acceso a la Instancianica del Solitario
para los clientes. Lo que ocurre en realidad con este mtodo es que, si Instancianica
no ha sido an creada, la crea (INICIALIZACIN PEREZOSA) llamando al constructor
Solitario, que no es pblico.
Son numerosos los ejemplos de clases de objetos que deben tener una nica
instancia. As, aunque un sistema tenga muchas impresoras, debe haber slo un
spooler. Debe haber, tambin, un nico sistema de ficheros y un nico gestor del
sistema de ventanas. Un filtro digital tendr slo un conversor A/D. Tomemos este ltimo
como ejemplo :
FILTRO DIGITAL
conversor
CONVERSOR A/D
Filtrar()
public :
static Conversor* Instancia()
protected :
Conversor()
if (Instancianica == 0)
Instancianica = new Conversor;
return Instancianica;
private :
static Conversor* Instancianica
________________________________________________________________________________
- 51 -
Banda de los Cuatro
conv = conversor -> Instancia();

conv.Convertir();
________________________________________________________________________________
- 52 -
Banda de los Cuatro
VISITANTE / VISITOR
Tipo
Propsito
Representar una operacin que est pensada para ser aplicada sobre los
elementos de una estructura de objetos, permitiendo as definir y aadir un nuevo
comportamiento sin necesidad de cambiar las clases de los elementos de la estructura de
objetos.
Estructura
CLIENTE
ELEMENTO
Aceptar(Visitante)
ESTRUCTURA
DE OBJETOS
VISITANTE
VisitarElementoA(ElementoA)
VisitarElementoB(ElementoB)
ELEMENTO A
ELEMENTO B
VISITANTE CONCRETO 1
VISITANTE CONCRETO 2
OperacinA()
Aceptar(Visitante v)
OperacinB()
v->VisitarElementoA(this);
v->VisitarElementoB(this);
Cuando usarlo
Cuando una Estructura De Objetos contiene muchas clases con diferentes
interfaces y se quieren aadir operaciones a dichos objetos en funcin de la interfaz.
Cuando se quieren aadir a los objetos de una estructura operaciones muy
diferentes y sin relacin alguna entre ellas, sin necesidad de hacerlo a nivel individual.
Cuando las clases que definen la Estructura De Objetos casi nunca cambian,
pero frecuentemente queremos aadir nuevas operaciones a ciertos objetos de la
estructura.
Ventajas
Es fcil aadir nuevas operaciones a la Estructura De Objetos; slo hay que
crear un nuevo Visitante, en vez de cambiar todas las clases a las que queremos que
afecte.
Se juntan las operaciones relacionadas entre s, separndose las que nada tienen
que ver. Esto simplifica tanto las clases de los Elementos como los algoritmos definidos
en los Visitantes.
Se pueden recorrer jerarquas formadas por objetos de distintos tipos (distinta
clase padre), mientras que un Iterador no puede hacer esto.
Se puede ir acumulando el estado a medida que se recorre la estructura, en vez
de tener que pasarlo como parmetro o guardarlo en variables globales.
Inconvenientes
________________________________________________________________________________
- 53 -
Banda de los Cuatro
Aadir un nuevo tipo de elemento a la estructura de objetos crea problemas, pues

hay que tocar toda la estructura jerrquica de Visitantes, lo cual es muy costoso.
Frecuentemente se fuerza a los Elementos a proporcionar operaciones pblicas
que den acceso a su estado interno, con lo que se pone en peligro el encapsulamiento.
Relacionado con
Visitante puede usarse para aplicar una operacin sobre una estructura de objetos
definida por Composicin.
Visitante puede utilizarse para implementar la operacin de interpretacin en el
patrn Intrprete.
La tcnica de programacin que posibilita aadir operaciones a las clases de la
Estructura De Objetos sin cambiarlos, recibe el nombre de double dispatch, pues su
ejecucin depende del tipo del peticionario y de los dos receptores : el Visitante y el
Elemento. Hay lenguajes (CLOS) que lo soportan directamente y otros (C++) que slo
tienen simple dispatch, por lo que deben pasar el Visitante como parmetro.
La responsabilidad de recorrer la Estructura De Objetos puede recaer en la
propia estructura (es frecuente), en un Iterador, que puede ser externo o interno (parecido
a la primera opcin, salvo en que ahora no hay double dispatch) o en el Visitante (nos
permite implementar una poltica compleja particular para el recorrido, pero duplica el
cdigo en cada Visitante concreto).
La Estructura De Objetos puede ser una composicin o una coleccin de objetos
(lista, conjunto, ... ) que proporciona una interfaz de alto nivel para que el Visitante
pueda acceder a todos sus Elementos.
En un compilador que representa los programas mediante rboles sintcticos
abstractos es mejor tener por un lado la jerarqua de nodos (declaraciones de asignacin,
acceso a variables, expresiones aritmticas, etc ... ) y por otro las operaciones que
queremos aplicarles (comprobacin de tipos, generacin de cdigo, anlisis de flujo,
optimizaciones, etc ... ) que tener todas las operaciones dentro de cada nodo, dado que
no a todos los nodos les afectan igual las distintas operaciones.
COMPILADOR
NODO
Aceptar(VisitanteDeNodo)
VISITANTE DE NODO
VisitarAsignacin(NodoAsignacin)
VisitarVariable(NodoVariable)
PROGRAMA
NODO_ASIGNACIN
NODO_VARIABLE
VISITANTE_COMPR_TIPOS
VISITANTE_GEN_CODIGO
v->VisitarAsignacin(this);
v->VisitarVariable(this);
________________________________________________________________________________
- 54 -

Patrones Gof

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Patrones Gof

Cargado por

Copyright:

Formatos disponibles

Unidad Docente de Ingeniera del Software

Facultad de informtica - Universidad Politcnica de Madrid

SOLITARIO / SINGLETON ...........................................................................................................................50

Banda de los Cuatro

Banda de los Cuatro

Para el caso de los botones el escenario es similar:

El problema de esta solucin es que se duplica la implementacin de la operacin que

Banda de los Cuatro

Los escenarios siguientes representan, respectivamente, la creacin y posterior

Banda de los Cuatro

Encapsular en un objeto la accin que satisface una peticin.

receptor -> Operacin()

Banda de los Cuatro

Banda de los Cuatro

Estructura, tanto a nivel de clases como a nivel de objetos.

A nivel de objetos ...

Banda de los Cuatro

Facilidad para redefinir el comportamiento de la clase adaptada.

texto -> ObtenerExtensin()

Banda de los Cuatro

Estructura, a nivel de objetos.

ElementoReal -> Peticin()

Banda de los Cuatro

Decorador puede tener una implementacin similar a la de Apoderado, a pesar de

Banda de los Cuatro

Banda de los Cuatro

CADENA DE RESPONSABILIDADES / CHAIN OF RESPONSIBILITY

Comportamiento, a nivel de objetos.

Banda de los Cuatro

Muchas personas ven Cadena de Responsabilidades como una Estrategia

Banda de los Cuatro

si puede dar la ayuda

Banda de los Cuatro

Estructura, a nivel de objetos.

para todos los hijos

Banda de los Cuatro

PesoMosca permite la comparticin de componentes, pero presenta problemas a

Banda de los Cuatro

Creacin, a nivel de objetos.

para todos los objetos de la estructura

La separacin (independencia) entre el proceso de construccin y la

Banda de los Cuatro

objetos (simples o complejos). Adems, en el primero el resultado se obtiene en el ltimo

Otros aspectos de inters

Banda de los Cuatro

while (t = siguiente token)

Elemento Grfico de Texto

Banda de los Cuatro

Estructura, a nivel de objetos.

Banda de los Cuatro

Gran fragmentacin5; el sistema se llena de gran cantidad de objetos pequeos, lo

Banda de los Cuatro

Comportamiento, a nivel de objetos.

estado -> Atender();

Banda de los Cuatro

PesoMosca explica como los objetos Estado pueden ser compartidos.

estado -> Abrir();

Banda de los Cuatro

Comportamiento, a nivel de objetos.

estrategia -> InterfazDelAlgoritmo();

Banda de los Cuatro

algoritmo -> DividirEnLineas();

Banda de los Cuatro

FBRICA ABSTRACTA / ABSTRACT FACTORY