UNIVERSIDAD NACIONAL DE

TRUJILLO

PATRN DE
DISEO
FACADE

1. DEFINICIN:

El patrn de diseo facade o fachada nos permite

simplificar el interface de comunicacin entre
dos objetos X y Z de tal forma que para el objeto
X sea ms sencillo interactuar con el objeto Z.
El Patrn Fachada se caracteriza por ser una
puerta de entrada hacia otro subsistema. Provee
una interfaz unificada y sencilla que haga de
intermediaria entre un cliente y una interfaz o
grupo de interfaces ms complejas.

2. OBJETIVO:

Agrupar las interfaces de un conjunto de

objetos en una interfaz unificada volviendo
a este conjunto ms fcil de usar por parte
de un cliente.
Encapsula la interfaz de cada objeto
considerada como interfaz de bajo nivel en
una interfaz nica de nivel ms elevado.

3. ESTRUCTURA:

Por ejemplo, se tiene la clase A debe saber cul es

exactamente la clase que le proporciona el servicio:
b1() es de B, c1() de C, d1() de D, ...

o el problema sera mayor, si hay ms de un cliente:

En estos caso, se puede usar este patrn de la siguiente

forma: Proporcionando una clase que implemente todos
los servicios (b1(),c1(),d1()). Los clientes slo usarn
dicha clase.

4. DIAGRAMA DE CLASES::

5. PARTICIPANTES:
Los participantes del patrn son los siguientes:
Fachada y su interfaz constituyen la parte abstracta
expuesta a los clientes del sistema. Esta clase posee
referencias hacia las clases y componentes que forman
el sistema y cuyos mtodos se utilizan en la fachada
para implementar la interfaz unificada.
Las
clases
y
componentes
del
sistema
implementan las funcionalidades del sistema y
responden a las consultas de la fachada. No necesitan
a la fachada para trabajar.

5. PARTICIPANTES:
Los participantes del patrn son los siguientes:
Fachada y su interfaz constituyen la parte abstracta
expuesta a los clientes del sistema. Esta clase posee
referencias hacia las clases y componentes que forman
el sistema y cuyos mtodos se utilizan en la fachada
para implementar la interfaz unificada.
Las
clases
y
componentes
del
sistema
implementan las funcionalidades del sistema y
responden a las consultas de la fachada. No necesitan
a la fachada para trabajar.

5. COLABORACIONES

Los clientes se comunican con el sistema a travs de la

fachada
Los objetos del subsistema realizan el trabajo final
Los clientes no tienen que accede directamente a los
subsistemas
La fachada no se limita solo a transmitir invocaciones

6. APLICACIONES
1. Un cliente necesita acceder a parte de una
funcionalidad
2. Grupos de tareas muy frecuentes
3. Una biblioteca es difcilmente legible
4. Dependencia entre el cdigo del cliente y parte
interna de la biblioteca
5. Acceso a un conjunto de APIs
6. Muchos clientes quieren usar varias clases
servidoras

PARA QU SE UTILIZA?

1. Promover una interfaz simple de un sistema

complejo
2. Dividir un sistema en subsistemas
3. Sistematizar la encapsulacin de la
implementacin de un sistema de cara al exterior

7. VENTAJA

Para modificar las

clases del
subsistema, solo
hay que modificar
las clases de los
subsistemas.

8. DESVENTAJAS

Si hay varios
subconjuntos
diferentes a los
cuales varios clientes
desean acceder,
puede que al final
solo se utilice una
parte de la fachada.

9. PATRONES
RELACIONADOS

10. CONCLUSIONES

1. Protege al cliente de los componentes del

sistema
2. Promueve un acoplamiento dbil
3. No evita que se use clases del subsistema