e Structural Es

Post on 25-Dec-2015

227 views 0 download

description

Patrones de diseño

Transcript of e Structural Es

PATRONES DE DISEÑO

Patrones Estructurales

Andrés Telloandres.tello@ucuenca.edu.ec

PATRONES ESTRUCTURALES

● Tratan de cómo están compuestas las clases y objetos para formar estructuras más grandes.

● Las clases Estructurales usan herencia e interfaces para la composición. – Ej. Cómo la herencia múltiple combina dos o más

clases en una. El resultado es una clase que combina las propiedades de todos sus padres.

● Muy útiles para lograr que librerías desarrolladas independientemente trabajen juntas

ADAPTER

● Intención:

Convertir la interfaz de una clase en la interfaz que el cliente espera. – Este patrón permite que dos clases con interfaces

incompatibles trabajen conjuntamente.

ADAPTER

● Motivación: – Adaptador entre dos clases u objetos

– Cómo en la vida real, es un adaptador o puente entre dos objetos.

● Adpatador para el cargador de una laptop.

– Desarrollo de Software:● Se tiene una clase que espera cierto tipo de objeto, y se tiene un objeto

que ofrece la misma funcionalidad pero que expone una interfaz diferente.

● Lo ideal es usar las dos sin tener que implementar de nuevo uno de las dos clases, tampoco se quiere modificar una de las clases.

– Solución: Crear un Adapter

ADAPTER

● Cuando usar:– Se requiere usar una clase en particular, pero su

interfaz no se adapta a la que usted necesita.

– Cuando se quiere crear una clase reutilizable que coopere con clases no previstas o no relacionadas. Dichas clases no necesariamente tienen interfaces compatibles

ADAPTER

Adapter usando herencia (Class Adapter)

ADAPTER

Adapter usando composición (Object Adapter)

ADAPTEREjemplo 1

ADAPTEREjemplo 2

ADAPTER

● Consecuencias:– Adapta una clase Adaptee a una clase Target, usando una

clase específica Adaptador

– Permite que la clase Adaptadora sobreescriba parte del comportamiento de la clase que se va a Adaptar(Adaptee), debido a que Adapter es una subclase de Adaptee

– Permite que un único adaptador pueda trabajar con varias clases a la vez

– Dificulta sobreescribir el comportamiento de la clase que se va a adaptar(Adaptee)

BRIDGE

● Intención:

Desacoplar una abstracción de su implementación de manera que las dos puedan variar independientemente

BRIDGE

● Motivación: – Una abtracción puede tener múltiples

implementaciones (herencia)

– Herencia ata la implementación a su abstracción de manera permanente

● Difuculta modificar, extender y reusar las dos independientemente

BRIDGE

BRIDGE

BRIDGE

● Cuando usar:– Se desea evitar un enlace permanente entre la abstracción y su

implementación. Esto puede ser debido a que la implementación debe ser seleccionada o cambiada en tiempo de ejecución.

– Tanto las abstracciones como sus implementaciones deben ser extensibles por medio de subclases. En este caso, el patrón Bridge permite combinar abstracciones e implementaciones diferentes y extenderlas independientemente.

– Cambios en la implementación de una abstracción no deben impactar en los clientes, es decir, su código no debe tener que ser recompilado.

BRIDGE

BRIDGE

● Participantes:– Abstraction: define una interface abstracta. Mantiene una

referencia a un objeto de tipo Implementor.

– RefinedAbstraction: extiende la interface definida por Abstraction

– Implementor: define la interface para la implementación de clases. Esta interface no se tiene que corresponder exactamente con la interface de Abstraction; de hecho, las dos interfaces pueden ser bastante diferente. Típicamente la interface Implementor provee sólo operaciones primitivas, y Abstraction define operaciones de alto nivel basadas en estas primitivas.

– ConcreteImplementor: implementa la interface de Implementor y define su implementación concreta.

BRIDGE

BRIDGE

BRIDGE

● Consecuencias:– Desacopla interface e implementación. La

implementación de una abstracción puede ser configurada en tiempo de ejecución. Además le es posible a un objeto cambiar su implementación en tiempo de ejecución.

– Mejora la extensibilidad: se puede extender las jerarquías de Abstraction e Implementor independientemente

– Esconde los detalles de la implementación a los clientes.

COMPOSITE

● Intención: – Facilita la creación de jerarquías de objetos donde

cada objeto se puede tratar de forma independiente o como un conjunto de objetos anidados a través de la misma interfaz.

COMPOSITE

● Cuando usar:– Se requiere representar jerarquías de objetos todo-

parte

– Los objetos y composiciones de objetos deben ser tratados de manera uniforme.

COMPOSITE

COMPOSITE

DECORATOR

● Intención: – Añade dinámicamente funcionalidad a un objeto.

– Permite no tener que crear subclases incorporando la nueva funcionalidad, sino otras que la implementan y se asocian a la primera.

DECORATOR

● Cuando usar:– El comportamiento de objetos debe ser

dinámicamente modificable, sin afectar otros objetos.

– Las funcionalidades específicas no deben residir en la parte alta de la jerarquía de objetos.

DECORATOR

DECORATOR

FACADE

● Intención: – Proporcionar una interfaz unificada de un conjunto

de interfaces de un subsistema

– Definir una interfaz de alto nivel que hace que un subsistema sea más fácil de utilizar

FACADE

● Cuando usar:– Se usa para proporcionar una interfaz sencilla para

un sistema complejo.

– Se quiere desacoplar un subsistema de sus clientes u otros subsistemas, haciéndolo mas independiente y portable.

– Se quiera dividir los sistemas en niveles: las fachadas serian el punto de entrada a cada nivel.

FACADE

FACADE

FLYWEIGHT

● Intención: – Eliminar o reducir la redundancia cuando tenemos

gran cantidad de objetos que contienen información idéntica

– Lograr un equilibrio entre flexibilidad y rendimiento (uso de recursos).

FLYWEIGHT

● Cuando usar:– Cuando la aplicación usa un gran número de objetos.

– Cuando el costo de almacenamiento es alto debido al número de objetos

– La gran mayoría de los estados de los objetos puede hacerse extrínseco.

– Al separar el estado extrínseco, muchos grupos de objetos pueden reemplazarse por unos pocos objetos compartidos.

FLYWEIGHT

FLYWEIGHT

Marca: ToyotaModelo: YarisColor: BlancoPlaca: XXXX

Marca: ToyotaModelo: YarisColor: RojoPlaca: 1234

Marca: ToyotaModelo: YarisColor: NegroPlaca: YYYY

Marca: ToyotaModelo: YarisColor: PlataPlaca: 5678

PROXY

● Intención: – Proporcionar un sustituto o intermediario para otro

objeto de modo que pueda controlarse el acceso que se tiene hacia él

PROXY

● Cuando usar:– Proxy remoto: cuando el objeto representado es

externo al sistema.

– Proxy virtual: Los objetos se deben crear bajo demanda. Se encarga de instanciar objetos cuyo coste computacional es elevado.

– Proxy de protección: establece controles de acceso a un objeto dependiendo de permisos o reglas de autorización.

PROXY