Desarrollo de adaptadores mediante WCF LOB Adapter SDK Roberto González – MVP BizTalk.
Patrones de Diseno Integrantes: Daniel Ferreira 02-34894 Yannick Estrada 02-34883 Ricardo Salinas...
-
Upload
candelaria-grande -
Category
Documents
-
view
223 -
download
0
Transcript of 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).
Patrón Observer (Observador)
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.
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:
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).
Patrón Observer (Observador)
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.
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
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.
Patrón Observer (Observador)
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).
Patrón Observer (Observador)
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.
Patrón Observer (Observador)
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().
Patrón Observer (Observador)
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
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 Observer (Observador)
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