patrones de diseno integrantes: daniel ferreira 02-34894 yannick estrada 02-34883 ricardo salinas...

Patrones de Diseno

Integrantes:

Daniel Ferreira 02-34894

Yannick Estrada 02-34883

Ricardo Salinas 03-36471

Flyweight

Observer

y Adapter

Patrón Flyweight

Referencias utilizadas:

Página Web Wikipedia:http://es.wikipedia.org/wiki/Flyweight_(patr%C3%B3n_de_dise%C3%B1o)

Página Web All App Labs: http://www.allapplabs.com/java_design_patterns/flyweight_pattern.htm

Página Web Fluffy Cat:http://www.fluffycat.com/Java-Design-Patterns/Flyweight/

Página Web Kybele (Grupo de Investigación):

http://kybele.escet.urjc.es/documentos/SI/Patrones/11_FlyWeight.ppt

Patron Flyweight

Tipo

Patrón estructural, determina como combinar objetos y clases para definir estructuras complejas.

Proposito

Compartir estados para soportar un gran número de objetos pequeños aumentando la eficiencia en espacio. El patrón Flyweight sirve para eliminar o reducir la redundancia cuando tenemos gran cantidad de objetos que contienen información idéntica.

Patron Flyweight

Motivacion

El patrón flyweight describe como almacenar un gran número de objetos sin un gran coste.

Para conseguir esto se utilizan objetos que almacenan los estados compartidos y que pueden ser usados por varios objetos simultáneamente.

Patron Flyweight

Estado intrínseco y extrínseco

1. El estado intrínseco es almacenado en el objeto.

2. El estado extrínseco es pasado (contexto) como parámetro en las operaciones.

Patron Flyweight

AplicabilidadSe 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

Patron Flyweight

Diagrama de clases

Patron Flyweight

Participantes1. Flyweight

Declara una interfaz a través de la cual los flyweights pueden recibir y actuar sobre los estados no compartidos.

2. ConcreteFlyweight

Implementa la interfaz Flyweight y almacena los estados compartidos, si los hay. Un objeto ConcreteFlyweight debe ser compartible. Cualquier estado que almacene debe ser intrínseco; es decir, debe ser independiente de su contexto.

Patron Flyweight

Patron Flyweight

Participantes (Continuacion)3. UnsharedConcreteFlyweight

No todas las subclases de Flyweight tienen por qué ser compartidas. La interfaz Flyweight permite que se comparta; no lo fuerza. Es común que los objetos de esta clase tengan hijos de la clase ConcreteFlyweight en algún nivel de su estructura.

4. FlyweightFactory

Crea y gestiona los objetos flyweight.

Garantiza que los objetos flyweight se comparten de forma apropiada. Cuando un cliente solicita un flyweight, el objeto de la clase FlyweightFactory proporciona una instancia existente, o crea una.

Participantes (Continuacion)

5. Client

Contiene referencias a los flyweights.

Calcula o almacena los estados no compartidos de los flyweights.

Patron Flyweight

Colaboraciones

Los clientes no crean directamente los objetos Flyweight, sino que deben invocar las fábricas

El estado extrínseco es mantenido por el cliente y pasado cuando se invocan métodos que lo requieren.

Patron Flyweight

Consecuencias

Ventajas:1. Produce ahorro de la capacidad almacenamiento

2. Reduce el número total de objetos

3. Reduce en gran cantidad el peso de los datos en un servidor .

Desventajas:

1. Consume un poco mas de tiempo para realizar las busquedas

Patron Flyweight

Ejemplo de alto nivelEstamos almacenando un texto con un determinado formato en el que cada carácter es un objeto representado por la letra en sí, el tamaño y la fuente.

Si ponemos el mismo formato a un párrafo entero, el tamaño y la fuente de cada carácter se repetiría cada vez y es un desperdicio de memoria innecesario.

Para ello utilizamos una nueva clase que almacene el tamaño y la fuente y hacemos que la clase anterior solo se componga de un atributo con la letra y otro atributo que referencie a la clase que acabamos de crear.

Patron Flyweight

Diagrama de Clases (Ejemplo)

Patron Flyweight

FormatoFactory

+pool: Formato()

+getFormato(tipo, tamano)

FormatoFlyweight

+tipo: String+tamano: int

+getTipo()+getTamano()

LetraConcreta

+letra: CharCliente

if ( exists formato(tipo,tamano) ) { return existing formato } else { create new formato(tipo, tamano) add new formato to the pool return the new formato }

Diagrama de clases del ejemplo

Diagrama de clases del patron

Patron Flyweight

FormatoFactory

+pool: Formato()

+getFormato(tipo, tamano)

FormatoFlyweight

+tipo: String+tamano: int

+getTipo()+getTamano()

LetraConcreta

+letra: CharCliente

if ( exists formato(tipo,tamano) ) { return existing formato } else { create new formato(tipo, tamano) add new formato to the pool return the new formato }

alt

Diagrama de Secuencia

Patron Flyweight

:Cliente

:LetraConcreta :FormatoFactory

format:FormatocrearLetra(letra,tipo,tamano

)

buscarFormato(tipo,tamano)

crear()

[existeFormato(tipo,tamano)]

else

setTamano(tamano)

format= getFormato(tipo,tamano)

setTipo(tipo)

format= getFormato(tipo,tamano)

asociarFormato(format)

crear ()

setLetra (letra)

return(format)

Patrón Observer

Referencias utilizadas

“Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Dessign and the Unified Process”

C. Larman Prentice Hall. Second Edition. 2002

www.cesaracebal.com/docencia/asignaturas/arquitectura

Patrón Observer (Observador)

PropositoDefine una dependencia uno-a-muchos entre objetos, de modo que cuando un objeto cambia su estado, todos los demás objetos dependientes se modifican y actualizan automáticamente.

Tipo de patrónComportamiento

Tambien conocido Publicar-Suscribir (Publish-Subscribe).


MotivaciónUn efecto lateral habitual de dividir un sistema en una colección de clases cooperantes es la necesidad de mantener una consistencia entre objetos relacionados, pero sin hacer a las clases fuertemente acopladas ya que eso reduciría su reutilización.

El patrón Observer describe como establecer estas relaciones. Los principales objetos de este patrón son el sujeto y el observador. Un sujeto puede tener cualquier numero de observadores. Cada vez que el sujeto cambia su estado se le notifica a todos sus observadores. En respuesta, cada observador consultara al sujeto para sincronizar su estado con el estado de este.


Pero…

¿Cómo dividir al sistema en clases sin que éstas estén fuertemente acopladas?


En Nueva Era…

Se pretende añadir la capacidad de que una ventana GUI actualice la información que muestra sobre el total de la venta cuando éste cambia.

Patrón Observer (Observador) En NuevaEra…¿porqué no vale la siguiente solución?

“Cuando la Venta cambia su total, el objeto Venta envía un mensaje a la ventana, pidiéndole que actualice la información que muestra.”

El principio de separación Modelo-Vista disuade de tales soluciones. Los objetos del modelo no deberían conocer los objetos de la vista o presentación.

De esa manera, se permite reemplazar la vista o capa de presentación por una nueva sin afectar a los objetos que no pertenecen a la interfaz de usuario.


AplicabilidadÚsese cuando:

1. Una abstracción tiene dos aspectos y uno depende del otro. Encapsular estos aspectos en objetos separados permite modificarlos y reutilizarlos de forma independiente.

2. Cuando un cambio en un objeto requiere cambiar otros y no sabemos cuantos objetos necesitan cambiarse.

3. Cuando un objeto debería ser capaz de notificar a otros sin hacer suposiciones sobre quienes son dichos objetos (no queremos que estos objetos estén fuertemente acoplados).


Estructura

Colaboraciones

1. SujetoConcreto notifica a sus observadores cada vez que se produce un cambio.

2. Después de ser informado de un cambio, un objeto ObservadorConcreto puede pedirle al sujeto más información. ObservadorConcreto usa esta información para sincronizar su estado con el del sujeto.


Consecuencias

El patrón Observer permite modificar los sujetos y observadores de forma independiente. Es posible reutilizar objetos sin reutilizar sus observadores y viceversa, permitiendo añadir observadores sin modificar el sujeto u otros observadores.


Ventajas

1. Acoplamiento abstracto entre Sujeto y Observador:

1.1 Todo lo que un sujeto sabe es que tiene una lista de observadores que se ajusta a la interfaz simple de la clase abstracta Observador.

1.2 El sujeto no conoce la clase concreta de ningún observador. Por lo tanto el acoplamiento entre sujetos y observadores es mínimo, pueden pertenecer a diferentes capas de abstracción de un sistema.


Ventajas (Continuacion)

2. Capacidad de comunicación mediante difusión: 2.1 A diferencia de una petición ordinaria, la notificación enviada por un sujeto no necesita especificar su receptor, se envía automáticamente a todos los objetos interesados que se hayan suscripto a ella. 2.2 Al sujeto no le importa cuantos objetos interesados haya; su única responsabilidad es notificar a sus observadores (libertad de añadir y quitar observadores en cualquier momento).


Desventajas1. Actualizaciones inesperadas:

1.1 Una operación aparentemente inofensiva sobre el sujeto puede dar lugar a una serie de actualizaciones en cascada de los observadores y sus objetos dependientes.

1.2 No se especifica el receptor de una Actualización, se envía a todos los objetos interesados.


Usos Conocidos1. El patrón Observer aparece en el Modelo Vista Controlador

(MVC). La clase Modelo desempeña el papel del Sujeto, mientras que Vista es la clase de los Observadores.

2. Este patrón suele observarse en los marcos de interfaces gráficas orientados a objetos.

3. En Java se puede heredar la funcionalidad del patrón Observer de la clase Observable y los observadores pueden implementar la interfaz Observer y por lo tanto redefinir el método update().


Implementacion Correspondecia entre objetos observados y

observadores

En vez de mantener una coleccion con referencias explicitas a los observadores en el suejeto, seria posible hacerlo con una tabla hash que relacionase ambos.

Es util cuando hay muchos sujetos y pocos observadores, para reducir costos de almacenamiento.

Implementacion (cont)

Observar mas de un objeto

Cuando un observador dependa de mas de un objeto, es necesatio ampliar la informacion de la operacion update.

Por ejemplo, incluyendose el sujeto a si mismo como parametro, para que el observador pueda discriminar


Evitar protocolos de actualizacion especificos de los observadores

Modelo Push: el sujeto envia informacion detallada a sus observadores sobre el cambio producido, la necesiten o no.

Modelo pull: los observadores solicitan la informacion que necesiten.


Especificar explicitamente el aspecto que varia

Podemos extender la interfaz de registro de observadores para que estos indiquen los eventos que les interesan

Cuando se produzca un evento, el objeto observado informara solo a los observadores intersados en ese evento

Conclusiones1. El observador proporciona un modo de acoplar

débilmente los objetos en terminos de la comunicación. Los sujetos conocen a los observadores solo a traves de una iterfaz.

2. El observador se basa en el polimorfismo, y proporciona variaciones protegidas en cuanto a que protege al sujeto del conocimiento de la clase especifica de objetos, y numero de objetos, con los que se comunica cuando genera un evento.


Patrón Adapter

Referencias utilizadas

http://www.cesaracebal.com/docencia/asignaturas/arquitectura-software/workspace/material/adapter.pdf

http://grasia.fdi.ucm.es/jpavon/patrones/patronesestructurales.pdf

http://eazel7.googlepages.com/Resumen20de20Patrones20de20Disenio.pdf

Tipo de patrón

Estructural

Ámbito

De clases y de objetos.

Otras denominaciones Wrapper (Envolvente)

Patrón Adapter

Propósito

Convertir la interfaz de una clase en otra interfaz que es la que esperan los clientes.

Permitir que cooperen clases que de otra forma no podrían por tener interfaces incompatibles.

Patrón Adapter

Aplicabilidad Se quiere usar una clase existente y su interfaz

no concuerda con la clase que necesita.

Se quiere crear una clase reutilizable que coopere con clases no relacionadas o que no han sido previstas (que no tienen por qué tener interfaces compatibles).

Cuando queremos usar varias subclases existentes, pero no resulta practico adaptar su interfaz heredando de cada una de ellas. Un adaptador de objetos puede adaptar la interfaz de su clase padre (Solamente en el caso de un adaptador de objetos).

Patrón Adapter

Estructura (Adaptador de clases) Un adaptador de CLASES usa herencia

múltiple para adaptar una interfaz a otra:

Patrón Adapter

Define la interfazexistente que

necesita adaptación

Adapta la interfazde Adaptable a la

interfaz de Objetivo.

Define la interfazespecífica al

dominioque utiliza el

cliente

Estructura en UML (clases)

Patrón Adapter

Patrón Adapter Estructura (Adaptador de objetos)

Un adaptador de OBJETOS se basa en la composición de objetos:

Define la interfazespecífica al

dominioque utiliza el

cliente

Adapta la interfazde Adaptable a la

interfaz de Objetivo.

Define la interfazexistente que

necesita adaptación

Patrón Adapter Estructura en UML (objetos)

Patrón Adapter

Ejemplo (Problema)

Supongamos que estamos haciendo un editor de dibujo:

• La abstracción fundamental es el objeto gráfico Shape, que puede dibujarse a sí mismo.

• Define una subclase para cada tipo de objeto gráfico: LineShape, PolygonShape...

Supongamos que, para implementar una subclase TextShape (bastante más compleja que las anteriores) queremos echar mano de una clase TextView que nos proporciona la biblioteca gráfica.

Patrón Adapter

Ejemplo (Solución)

Se crea una clase TextShape que adapte la interfaz de TextView a la de Shape, de manera que el editor gráfico (DrawingEditor) pueda reutilizar la clase TextView, que de otra manera sería incompatible.

Patrón Adapter

Ejemplo (Opciones)

Heredando la interfaz de Shape y la implementación de TextView (Adapter de clases).

Componiendo un objeto TextView en un TextShape, que se implementa utilizando en objeto TextView (Adapter de objetos).

Patrón Adapter

Ejemplo (Adapter de objetos)

Clase Adaptador

a

Clase Adaptad

a

Participantes Objetivo: Define la interfaz especifica del dominio que

usa el Cliente. (Shape) Cliente: Colabora con objetos que se ajustan a la interfaz

Objetivo. (DrawingEditor) Adaptable: Define una interfaz existente que necesita

ser adaptada. (TextView) Adaptador: Adapta la interfaz de Adaptable a la interfaz

Objetivo. (TextShape)

ColaboracionesLos clientes llaman a operaciones de una instancia de

Adaptador. A su vez, el Adaptador llama a operaciones de Adaptable, que son las que satisfacen la petición.

Patrón Adapter

Consecuencias (Adaptador de clases)

Permite que el Adaptador redefina parte del comportamiento de Adaptable, por ser Adaptador una subclase de Adaptable. (Ventaja)

Adapta una clase Adaptable a Objetivo, pero se refiere a una clase Adaptable concreta (no nos servirá cuando queramos adaptar una clase y todas sus subclases). (Desventaja)

Patrón Adapter

Patrón Adapter

Consecuencias (Adaptador de objetos)

Permite que un mismo Adaptador funcione con el Adaptable y todas sus subclases. El Adaptador también puede añadir funcionalidad a todos los adaptables a la vez. (Ventaja)

Hace que sea más difícil redefinir el comportamiento de Adaptable. Se necesitará crear una subclase de Adaptable y hacer que el Adaptador se refiera a la subclase en vez de a la clase Adaptable en sí. (Desventaja)

Patrones relacionados

Bridge Tiene una estructura similar a un adaptador de

objetos, pero con un propósito diferente: está pensado para separar una interfaz de su implementación, de manera que ambos puedan cambiar fácilmente y de forma independiente uno del otro, mientras que un adaptador esta pensado para cambiar la interfaz de un objeto existente.

Patrón Adapter

Patrón Adapter Patrones relacionados

Decorator Decora otro objeto sin cambiar su interfaz. Un

Decorator es por tanto más transparente a la aplicación que un adaptador. Como resultado, el patrón Decorator permite la composición recursiva, lo que no es posible con adaptadores puros.

ProxyDefine un representante o sustituto de otro objeto sin

cambiar su interfaz.

Cuestiones a tener en cuenta

Cuánta adaptación hace el AdaptadorDifieren en la cantidad de trabajo necesaria para

adaptar Adaptable a la interfaz Objetivo. Esto depende de lo parecida que sea la interfaz de Objetivo a la de Adaptable.

Adaptadores conectablesUna clase es mas reutilizable cuando minimizamos

las asunciones que deben hacer otras clases para usarla.

Adaptadores BidireccionalesResultan útiles cuando dos clientes distintos

necesitan ver un objeto de distinta forma.

Patrón Adapter

Conclusión

Adapter se centra en resolver incompatibilidades entre dos interfaces existentes.

No presta atención a cómo se implementan dichas interfaces, ni tiene en cuenta cómo podrían evolucionar de forma independiente.

Es un modo de lograr que dos clases diseñadas independientemente trabajen juntas sin tener que volver a implementar una u otra.

Patrón Adapter

GRACIAS

patrones de diseno integrantes: daniel ferreira 02-34894 yannick estrada 02-34883 ricardo salinas...

Documents