ESCUELA SUPERIOR POLITECNICA DE CHIMBORAZO

FACULTAD DE INFORMATICA Y ELECTRONICA

INGENIERIA EN SISTEMAS
Arquitectura de Software

Patrón Flyweight

María José Quinatoa 6216

Patrón Flyweight

Tipo: Patrón estructural

Propósito: Busca eliminar o reducir la redundancia cuando tenemos gran

cantidad de objetos.

Intención: Reduce la redundancia cuando gran cantidad de objetos poseen

idéntica información.

Patrones Relacionados: Abstract Factory, Composite, State y Strategy.

Estructura
Participantes
■ Flyweight: declara la interfaz que utilizan los flyweights para actuar en
estado extrínseco.
■ ConcreteFlyweight: implementa el flyweight y agrega almacenamiento
para el estado intrínseco (que debe ser compartible).
■ UnsharedConcreteFlyweight: no todos los flyweight necesitan ser
compartidos.
■ FlyweightFactory: crea y gestiona objetos de peso mosca. Se garantiza
que los pesos al vuelo se comparten correctamente.
■ Cliente: almacena el estado extrínseco de los flyweights
Ejemplo

Se requiere utilizar un programa el cual se le cargara "varios autos" y al

pedirle el detalle del mismo, muestre patente, color, dueño. Hay que
tener en cuenta que debe ocupa poca memoria ya que es un proyecto
masivo.
Ejemplo

■ Solución
Ejemplo
IVehiculo
Ejemplo
Auto
Ejemplo
FlyweightFactory
Ejemplo
Main
Ejemplo

■ Salida
Aplicabilidad
Se debe aplicar este patrón cuando se cumplen todas estas
características:
■ Se utiliza un gran número de objetos
■ El coste de almacenamiento es alto debido a la cantidad de objetos
■ La mayoría de los estados de los objetos pueden ser creados como
comunes.
■ Muchos objetos pueden ser reemplazados por unos pocos una vez
que han sido borrados los estados no comunes.
■ La mayor parte del estado del objeto puede ser extrínseco
Consecuencias
■ Reduce en gran cantidad el peso de los datos en un servidor.
■ Consume un poco más de tiempo para realizar las búsquedas.
■ Se complica la codificación lo que puede redundar en el
aumento en la aparición de errores.
■ El cliente debe tener algún conocimiento de la implementación.
Por esto, puede romper con la estructura cliente-servidor.
Referencias

■ PDF-Departamento de Sistemas Informáticos y Programación Curso

de doctorado 1999 - 2000 Patrones de diseño orientado a objetos.

■ DesIgn Patterns: Elements of Reusable Object-Oriented Software

Gamma, Helm, Johnson, Vlissides Editorial Addison-Wesley.
 ESCUELA SUPERIOR POLITECNICA DE CHIMBORAZO
FACULTAD DE INFORMATICA Y ELECTRONICA
INGENIERIA EN SISTEMAS
Arquitectura de Software

Patrón Mediator

María José Quinatoa 6216

Valeria Zurita 6101
Patrón Mediator
Tipo: Patrón de comportamiento.

Propósito: Simplificar la comunicación entre los objetos de un sistema introduciendo un

único objeto que gestiona la distribución de mensajes entre los otros.

Patrones relacionados:

Facade (fachada): Se diferencia en el uso ya que este abstrae un conjunto de objetos

usando un protocolo unidireccional mientras que Mediador utiliza un protocolo
multidireccional.

Observer (Observador): Mediante este patrón los objetos pueden comunicarse con el
Mediador.
Estructura
Participantes
■ Mediador: Define una interfaz para comunicarse con los otros objetos

■ Colega: Cada Colega conoce su Mediador, y usa a este para comunicarse

con otros Colegas.

■ ColegaConcreto: Implementa el comportamiento del Colega.

■ MediadorConcreto: Implementa el comportamiento cooperativo entre los

Colegas (como se comunican entre ellos). Además los conoce y
mantiene.
Ejemplo

Nuestro ejemplo será un chat: donde habrá usuarios que se comunicaran entre sí en
un salón de chat. Para ellos se define una interface llamada IUsuarioChat que todos los
objetos que quieran participar de un chat deberán implementar. La clase Usuario
representa un usuario que quiera chatear.
Ejemplo
Diagrama
Ejemplo

IUsuarioChat

ISalonDeChat
Ejemplo

Usuario
Ejemplo

SalonDeChat
Ejemplo

Mediator(Main)
Ejemplo

Resultado
Aplicabilidad

Utilizaremos el patrón Mediator cuando:

■ Un conjunto grande de objetos se comunica de una forma bien definida,

pero compleja.

■ Dificultad para reutilizar objetos ya que nos referimos a varios objetos para
comunicarnos.

■ El comportamiento de muchos objetos que esta distribuido entre varias

clases, puede resumirse en una o varias por subclasificación.
Consecuencias

■ Evita crear subclases de los colegas, sólo se crean subclases del

mediador.

■ Desacopla a los colegas.

■ Simplifica los protocolos entre las clases

■ Abstrae el cómo cooperan los objetos

■ Centraliza el control en el mediador: clase difícil de mantener

Referencias

■ Design Patterns Elements of Reusable Object-Oriented Software, GoF.

■ http://dc.exa.unrc.edu.ar/nuevodc/materias/sistemas/2007/Patrone
s/1181918751/MediatorRes2.pdf
■ http://kybele.escet.urjc.es/documentos/SI/Patrones/14_Mediator.pp
t
 ESCUELA SUPERIOR POLITECNICA DE CHIMBORAZO
FACULTAD DE INFORMATICA Y ELECTRONICA
INGENIERIA EN SISTEMAS
Arquitectura de Software

Patrón Memento

María José Quinatoa 6216

Valeria Zurita 6101
Patrón Memento
Tipo: Patrón de comportamiento, también conocido como recuerdo

Propósito: Guardar el estado de un objeto sin romper el encapsulamiento del mismo

Intención: Guarda parte o todo el estado interno de un objeto, para que este objeto pueda ser
restaurado más tarde al estado guardado por Memento

Patrones relacionados:

Command (Comando): Puede usar Mementos para restaurar sus operaciones almacenadas.

Iterator (Iterador): Puede usarse con Iterador para buscar colecciones de estados específicos.
Estructura
Participantes
■ Memento: Almacena el estado de un objeto Originador. Memento
almacena todo o parte de Originador. Tiene dos interfaces, una para
Aplicación que le permite comunicarse con otros objetos y otra para
Originador que le permite almacenar el estado

■ Originador: Crea un objeto Memento con una copia de su estado. Usa

Memento para restaurar el estado almacenado.

■ Conserje: Mantiene a Memento pero no opera con su contenido.

Ejemplo

Vamos a realizar un ejemplo de este patrón donde se busque salvar el nombre de una
persona que puede variar a lo largo del tiempo.
Ejemplo

Diagrama
Ejemplo

Memento
Ejemplo

Persona
Ejemplo

Conserje
Ejemplo

Main
Ejemplo

Resultado
Aplicabilidad

■ Todo o parte del objeto debe de ser almacenado para una posible
restauración del mismo.
■ Cuando una interfaz directa para obtener el estado de un objeto
exponga detallas de su implementación.
Colaboraciones

■ Almacena durante un tiempo y se lo devuelve a su creador, tal y como

muestra el diagrama.
■ A veces la aplicación(Caretaker) no devolverá el memento a su
creador, ya que el creador podría no necesitar nunca volver a un
estado anterior.
■ Los mementos son pasivos. Sólo el creador que creó el memento
asignará o recuperará su estado.
Consecuencias

■ Mantiene la encapsulación
■ Simplifica la clase Creador ya que no debe preocuparse de
mantener las versiones del estado interno.
■ Podría incurrir en un considerable gasto de memoria: encapsular
y restaurar el estado no debe ser costoso.
■ Puede ser difícil en algunos lenguajes asegurar que sólo el
Creador tenga acceso al estado del Memento.
Referencias

■ Design Patterns Elements of Reusable Object-Oriented Software, GoF.

■ http://www.ldc.usb.ve/~mgoncalves/IS2/sd07/grupo3.pdf
■ http://kybele.escet.urjc.es/documentos/SI/Patrones/15_MEMENTO.
ppt
■ http://www.freewebz.com/amanecer/personal/papers/paper.memen
to.pdf