ANDRES FELIPE BORRERO SALAZAR COD ALEXANDRA CARREÑO SALAS COD LUCIO ANIBAL CRIOLLO COD ALEJANDRO RUIZ IDROBO COD

Patrón Fachada El patrón fachada trata de simplificar la interface entre dos sistemas o componentes de software ocultando un sistema complejo detrás de una clase que hace las veces de pantalla o fachada, de tal forma que su uso sea más fácil.

Motivación Reducir la complejidad de un sistema, al ser dividido en componentes mas sencillos e independientes entre sí. Se aíslan los posibles cambios que se puedan producir en alguna de las partes. Si cambias, por ejemplo, el medio de comunicación o de almacenamiento de una de las partes, la otra, que por ejemplo hace la presentación, no tiene porque enterarse, y viceversa.

Aplicabilidad : Necesidad de proporcionar una interfaz simple para un sistema complejo. A medida que un subsistema evoluciona va teniendo más clases, más pequeñas, más flexibles y configurables. Hay clientes que no necesitan tanta flexibilidad y que quieren una visión más simple del subsistema. Sólo los clientes que necesiten detalles de más bajo nivel accederán a las clases detrás de la fachada

Aplicabilidad Necesidad de reducir la dependencia entre las clases que implementan un subsistema y sus clientes. La fachada desacopla el subsistema de los clientes y de otros subsistemas. Esto mejora la independencia de subsistemas y la portabilidad. Para estructurar un sistema en capas La fachada define el punto de entrada a cada nivel. Se pueden simplificar las dependencias obligando a los subsistemas a comunicarse únicamente a través de sus fachadas.

Consecuencias ● ● Oculta a los clientes los componentes del subsistema. ● ● Reduce el número de objetos con los que tienen que tratar los clientes. ● ● Disminuye el acoplamiento entre un subsistema y sus clientes ● ● Un menor acoplamiento facilita el cambio de los componentes del subsistema sin afectar a sus clientes. ● ● Las fachadas permiten estructurar el sistema en capas ● ● Reduce las dependencias de compilación ● ● No evita que las aplicaciones puedan usar las clases del subsistema si resulta necesario. ● ● Se puede elegir entre facilidad de uso y generalidad

Estructura:

Participantes Fachada Conoce las clases del subsistema responsables de una determinada operación. Delega las peticiones de los clientes a los objetos apropiados del subsistema. Clases del subsistema Implementan la responsabilidad del subsistema Realizan el trabajo solicitado (por la fachada) No saben de la existencia de la fachada

Implementación y Patrones Asociados ● Reducción del acoplamiento cliente-subsistema Se puede reducir más el acoplamiento haciendo la fachada una clase abstracta con subclases concretas para las distintas implementaciones del subsistema. Otra posibilidad es configurar el objeto fachada con diferentes objetos del subsistema. Para personalizar la fachada basta con reemplazar uno o varios de sus objetos del subsistema. La factoría abstracta se puede utilizar junto a la fachada para crear objetos del subsistema de manera independiente al subsistema.

● Normalmente se accede a la fachada por medio de un patrón singleton. Proporcionan variaciones protegidas de la implementación de un subsistema, añadiendo un objeto de indirección que ayudan a mantener el bajo acoplamiento.

Ejemplo ● Considere la construcción de un conjunto de clases para apoyar la creación y envío de mensajes de .

● El problema es que el cliente debe conocer al menos 6 clases, las relaciones entre ellas y el orden en que deben ser creadas. El patrón Fachada le oculta al cliente el conjunto de clases, separando la funcionalidad, de las clases que la utilizan o clientes.