PATRON DE DISEO

FACHADA O
FACADE

PATRON DE DISEO FACHADA

ESTRUCTURAL

CLASIFICACIN:

TEXTO

PROPSITO:

PROPORCIONAR UNA INTERFAZ NICA PARA UN CONJUNTO DE

INTERFACES EN UN SUBSISTEMA. EL OBJETIVO ES DEFINIR LA INTERFAZ
DE NIVEL MS ALTO DE LAS OPERACIONES QUE REALIZA EL SUBSISTEMA
PARA QUE SEA MS SENCILLO EL USARLO POR OTROS MDULOS O
SUBSISTEMAS DIFERENTES, ES DECIR FACILITAR EL ACCESO.

TEXTO

MOTIVACIN:
En general la divisin de un sistema complejo en
subsistemas facilita el poder abordar el problema y
reduce la complejidad.
El objetivo que se persigue es minimizar las
comunicaciones y puntos de acceso de un
subsistema a otro de modo que la dependencia entre
subsistemas se reduzca. Es decir, disminuir el
acoplamiento entre sistemas.

APLICABILIDAD

PROPORCIONAR UNA INTERFAZ SIMPLE PARA

UN SUBSISTEMA COMPLEJO.
Hace que un subsistema sea mas reutilizable y fcil
de usar.

Hace mas fcil de usar para aquellos clientes que no

necesiten personalizarlo.
La fachada proporciona un punto de vista simple por
defecto del subsistema y slo los clientes que
necesiten mayor grado de personalizacin accedern
directamente al subsistema sin hacerlo mediante la
fachada

APLICABILIDAD

HAYA MUCHAS DEPENDENCIAS ENTRE LOS CLIENTES Y LAS

CLASES QUE IMPLEMENTAN UNA ABSTRACCIN

Introduce una fachada para desacoplar el subsistema

de sus clientes y de otros.
intenta acotar que un cambio en el subsistema no se
propague al exterior promoviendo la independencia
de los subsistemas y su portabilidad.

TEXTO

QUERAMOS DIVIDIR EN SUBCAPAS

NUESTROS
SUBSISTEMAS
Usa una fachada para definir un punto de entrada en
cada nivel del subsistema.

Se pueden simplificar las dependencias entre ellos

haciendo que se comuniquen entre si a travs de sus
fachadas.

FACHADA O FACADE

ESTRUCTU

ESTRUCTURA

FACHADA O FACADE

PARTICIPA

PARTICIPANTES

Fachada o Facade (Compiler): Conoce las clases del

subsiste responsables de una determinada operacin
que se les est ofertando a los clientes. Cuando un
cliente le realiza una peticin delega las peticiones en
los objetos apropiados del subsistema; es decir, las
clases realizan el proceso, la fachada no asume la
responsabilidad.
Clases del subsistema (Scanner, Parser, ProgramNode,
etc.): Implementan la funcionalidad del subsistema
realizando el trabajo solicitado por la Fachada. Estas
clases no conocen la existencia de la Fachada (no
tienen referencias a la fachada).

FACHADA

CONSECUE

CONSECUENCIAS

Oculta a los clientes los componentes del

subsistema, haciendo que el sistema sea ms fcil de
usar
Promueve un dbil acoplamiento entre el subsistema
y sus clientes.
No impide que las aplicaciones usen las clases del
subsistema, de ser necesario. De este modo se
puede elegir entre facilidad de uso y generalidad.

FACHADA

EJEMPLO

EJEMPLO

Un ejemplo de este patrn aplicado a la vida real

sera la diferencia entre un sistema de cambio
manual y un sistema automtico. En el primer caso,
el conductor debe interactuar con el embrague, el
acelerador y la palanca de cambios, mientras que en
el segundo caso, el conductor nicamente tiene que
preocuparse de acelerar o decelerar, puesto que ser
el propio vehculo el que se encargar de realizar
todo el proceso.

EJEMPLO

EJEMPLO

EJEMPLO
Si nos fijamos bien en la implementacin del patrn, nos daremos cuenta de un
par de detalles:
El patrn contiene una referencia a cada uno de los elementos que encapsula,
que son inyectados a travs del constructor (recordemos: la inyeccin de
dependencias es tambin una buena prctica de programacin orientada a
objetos).
Los parmetros que recibe el constructor son interfaces en lugar de clases.
Otro buen principio de programacin orientado a objetos era el de depender de
abstracciones, no de concreciones.
La existencia de la clase Centralita no implica que las clases no puedan
utilizarse tal y como las usbamos hasta el momento: este patrn no reduce la
visibilidad de los objetos que encapsula, simplemente ofrece una alternativa
simplificada de su uso.
Al encapsular las clases dentro de Centralita estamos desacoplando las clases
contenidas en ella del resto de clases cliente, centralizando los cambios en el
supuesto de que alguna de las clases acopladas cambie. Ojo! Si decidimos
seguir utilizando las clases encapsuladas por otros medios, no estaremos
reduciendo el acoplamiento.