PATRONES DE DISEO ESTRUCTURALES

Bentez Ochoa Daniel Hernndez Ramos Kevin Alfonso Martnez Velzquez Lilian Rosquero Ortiz Berenice Trejo Salazar Jos Rogelio
Equipo 2:

Bridge Facade Decorator

Bridge
Objetivo:
Desacopla una abstraccin de su implementacin de manera que las dos puedan evolucionar independientemente.
Permite la manipulacin de la implementacin en tiempo de ejecucin.

Otras denominaciones:

Handle/Body

Motivacin

La herencia permite que una abstraccin tenga varias implementaciones: esta relacin se define en tiempo de compilacin. Hay casos en los que puede haber una gran jerarqua de clases de una abstraccin (p.ej. Window, IconWindow, TransientWindow) y varias jerarquas de implementacin (en diferentes plataformas) No es necesario desacoplar la abstraccin de la implementacin

Aplicabilidad
Se usa el patrn Bridge cuando: Se desea evitar un enlace permanente entre la abstraccin y su implementacin. Tanto las abstracciones como sus implementaciones deben ser extensibles por medio de subclases. En este caso, el patrn Bridge permite combinar abstracciones e implementaciones diferentes y extenderlas independientemente. Cambios en la implementacin de una abstraccin no deben impactar en los clientes, es decir, su cdigo no debe tener que ser recompilado. Se desea compartir una implementacin entre mltiples objetos (quiz usando contadores), y este hecho debe ser escondido a los clientes.

Estructura

Participantes

Abstraction define una interface abstracta. Mantiene una referencia a un objeto de tipo Implementor. RefinedAbstraction extiende la interface definida por Abstraccin Implementor define la interface para la implementacin de clases. Esta interface no se tiene que corresponder exactamente con la interface de Abstraccin; de hecho, las dos interfaces pueden ser bastante diferente. Tpicamente la interface Implementor provee slo operaciones primitivas, y Abstraccin define operaciones de alto nivel basadas en estas primitivas. ConcreteImplementor implementa la interface de Implementor y define su implementacin concreta.

Consecuencias
Se desacopla interfaz e implementacin La implementacin no est vinculada permanentemente a la interfaz, y se puede determinar en tiempo de ejecucin (incluso cambiar)

Bridge:

Se eliminan dependencias de compilacin Se consigue una arquitectura ms estructurada en niveles Se mejora la extensibilidad Las jerarquas de abstraccin y de implementacin pueden evolucionar independientemente Se esconden detalles de implementacin a los clientes

Facade
Provee

una interfaz unificada para un conjunto de interfaces de un subsistema. Facade define una interfaz de alto nivel que hace, el subsistema fcil de usar.

Propsito:
Simplifica

el acceso a un conjunto de objetos proporcionando uno que todos los clientes pueden usar para comunicarse con el conjunto

Aplicabilidad
Quiere proveer una interfaz nica para un subsistema complejo. Esto ayuda a que un subsistema sea ms reusable y fcil de adaptar.

Usar patrn facade cuando:

Hay muchas dependencias entre clientes y clases que implementan una abstraccin. Con el patrn facade se desacopla el cliente del subsistema, as como entre subsistemas; esto promueve subsiste-mas independientes y portables. Usted quiere dividir en capas su subsis-tema. Use facade para definir el punto de entrada a cada nivel del subsistema.

Estructura

Participantes
Facade: conoce que clases son responsable de una peticin. Delega las peticiones del cliente a objetos del subsistema apropiados.

Subsystem classes: implementa la funcionalidad del subsistema, maneja el trabajo asignado por facade. Desconocen a facade, lo que indica que no tienen referencia a este.

Colaboracin

El cliente se comunica con el subsistema transmitiendo peticiones a facade, que se encarga, luego, de enviarlas a los ob-jetos apropiados. Facade tambin puede realizar algn trabajo, debido a la traduc-cin de su interface a la interface que el subsistema posee. El cliente que utiliza facade no tiene acceso al subsistema directamente.

Consecuencias
Facade ofrece los siguientes beneficios:
Protege al cliente de los componentes del subsistema, as reduce el nmero de objetos con los que el cliente se relaciona. Y hace ms fcil de usar al subsiste-ma. Promueve un acoplamiento dbil entre el cliente y el subsistema. Esto permite modificar componentes en el subsistema sin modificar el cliente. No evita que se use clases del subsistema si la aplicacin la necesita.

Decorador
Propsito:
Asignar nuevas responsabilidades a un objeto dinmicamente. Es una alternativa a la creacin de subclases por herencia

Otras denominaciones:

Decorator

Wrapper

Motivacin

Para aadir nuevas responsabilidades a objetos individuales y no a toda la clase Por ejemplo, una ventana de una interfaz grfica puede tener bordes, scrolling, u otros artefactos Esto se puede hacer dinmicamente

Aplicacin
Para

asignar responsabilidades a objetos individuales de forma dinmica y transparente, sin afectar a otros objetos. Para responsabilidades que pueden ser suprimidas. Cuando no es prctico utilizar herencia de clases (porque se producira una explosin del nmero de clases, o porque no se tiene la definicin de la clase)

Estructura

Consecuencias
Ms flexibilidad que la herencia de clases (esttica) Las responsabilidades se aaden y quitan dinmicamente (en tiempo de ejecucin) Evita la explosin de clases Permiten aadir una propiedad ms de una vez ; aadir doble borde a una ventana. Se puede definir una clase sencilla y aadirle nuevas caractersticas mediante decoradores, pudiendo as obtener gran funcionalidad combinando piezas sencillas. Slo se incorpora lo que se usa. Muchos componentes pequeos. Al usar Decoradores, el sistema tiene muchos objetos pequeos. Puede ser difcil de entender y depurar