Patrones de Diseno Flyweight Observer y Adapter Integrantes: Daniel Ferreira 02-34894 Yannick Estrada 02-34883 Ricardo Salinas 03-36471

Patrón Flyweight

Patron 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 Proposito 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 El estado intrínseco es almacenado en el objeto. El estado extrínseco es pasado (contexto) como parámetro en las operaciones.

Patron Flyweight 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

Patron Flyweight Diagrama de clases

Patron Flyweight Participantes 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 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.

Patron Flyweight 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: Desventajas: Produce ahorro de la capacidad almacenamiento 2. Reduce el número total de objetos 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 nivel Estamos 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 Diagrama de clases del patron Diagrama de clases del ejemplo

Patron Flyweight Diagrama de Secuencia :Cliente :LetraConcreta :FormatoFactory format:Formato crearLetra(letra,tipo,tamano) crear () setLetra (letra) buscarFormato(tipo,tamano) alt [existeFormato(tipo,tamano)] format= getFormato(tipo,tamano) else crear() setTipo(tipo) setTamano(tamano) format= getFormato(tipo,tamano) return(format) asociarFormato(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) Proposito Define 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ón Comportamiento Tambien conocido Publicar-Suscribir (Publish-Subscribe).

Patrón Observer (Observador) Motivación Un 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.

Patrón Observer (Observador) Pero… ¿Cómo dividir al sistema en clases sin que éstas estén fuertemente acopladas?

Patrón Observer (Observador) 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.

Patrón Observer (Observador) Aplicabilidad Úsese cuando: Una abstracción tiene dos aspectos y uno depende del otro. Encapsular estos aspectos en objetos separados permite modificarlos y reutilizarlos de forma independiente. Cuando un cambio en un objeto requiere cambiar otros y no sabemos cuantos objetos necesitan cambiarse. 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).

Patrón Observer (Observador) Estructura

Patrón Observer (Observador) Colaboraciones SujetoConcreto notifica a sus observadores cada vez que se produce un cambio. 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.

Patrón Observer (Observador)

Patrón Observer (Observador) 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.

Patrón Observer (Observador) Ventajas 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.

Patrón Observer (Observador) Ventajas (Continuacion) 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).

Patrón Observer (Observador) Desventajas 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.

Patrón Observer (Observador) Usos Conocidos 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. Este patrón suele observarse en los marcos de interfaces gráficas orientados a objetos. 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

Implementacion (cont) 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.

Implementacion (cont) 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

Patrón Observer (Observador) Conclusiones 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. 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

Patrón Adapter Estructural De clases y de objetos. Tipo de patrón Á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: Define la interfaz existente que necesita adaptación Adapta la interfaz de Adaptable a la interfaz de Objetivo. específica al dominio que utiliza el cliente

Patrón Adapter Estructura en UML (clases)

Patrón Adapter Estructura (Adaptador de objetos) Un adaptador de OBJETOS se basa en la composición de objetos: Define la interfaz específica al dominio que utiliza el cliente Adapta la interfaz de Adaptable a la interfaz de Objetivo. existente 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 Adaptada Clase Adaptadora Clase Adaptada

Patrón Adapter Participantes Colaboraciones 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) Colaboraciones Los 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 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)

Patrón Adapter 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 Patrones relacionados Decorator Proxy 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. Proxy Define un representante o sustituto de otro objeto sin cambiar su interfaz.

Patrón Adapter Cuestiones a tener en cuenta Cuánta adaptación hace el Adaptador Difieren 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 conectables Una clase es mas reutilizable cuando minimizamos las asunciones que deben hacer otras clases para usarla. Adaptadores Bidireccionales Resultan ú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.

GRACIAS