Patrón Facade (fachada): Ejemplo de Inmobiliaria

Patrón de Fachada: 

Ejemplo de Inmobiliaria

Busca simplificar el sistema, desde el punto de vista del cliente, proporcionando una interfaz unificada para un conjunto de subsistemas, definiendo una interfaz de nivel más alto. Esto hace que el sistema sea más fácil de usar. 

Este patrón busca reducir al mínimo la comunicación y dependencias entre subsistemas. Para ello, utilizaremos una fachada, simplificando la complejidad al cliente. El cliente debería acceder a un subsistema a través del Facade. De esta manera, se estructura un entorno de programación más sencillo, al menos desde el punto de vista del cliente (por ello se llama "fachada").

Ref: http://migranitodejava.blogspot.com.es/2011/06/facade.html

Organización del programas sin usar el patrón y usandolo.
(http://powerdream5.wordpress.com/tag/facade-pattern/ )

Los clientes se comunican con el subsistema a través de la facade, que reenvía las peticiones a los objetos del subsistema apropiados y puede realizar también algún trabajo de traducción. Los clientes que usan la facade no necesitan acceder directamente a los objetos del sistema.

Ejemplo:  (ref:  http://migranitodejava.blogspot.com.es/2011/06/facade.html )
Vamos a realizar el software para una inmobiliaria. Una inmobiliaria realiza muchos trabajos diferentes, como:
- el cobro de alquiler
- muestra de inmuebles
- administración de consorcios
- contratos de ventas
- contratos de alquiler
- etc.

Por una cuestión de seguir el paradigma de programación orientada a objetos, es probable que no se realice todo a una misma clase, sino que se dividen las responsabilidades en diferentes clases.

En el soft de la inmobiliaria tenemos diversos tipos de Personas, todas con sus atributos y métodos correspondientes.Lo mismo con los métodos principales de las diversas clases que tiene el sistema.

Ahora haremos una clase llamada Inmobiliaria que será nuestro Facade

Para ver las ventajas de usar el patrón, veamos ahora 2 tipos de clientes.
-> El primero no llamará al Facade
-> y el segundo si lo utilizará.
Veremos como el primero esta obligado a conocer muchos detalles de los subsistemas y el segundo no.
Proyecto:

Las clases:
Clase AdministracionAlquiler

Clase CuentasAPagar

Clase MuestraPropiedad

Clase VentaInmueble

Clase Inmobiliaria (esta clase hará la función clase FACADE "fachada")

Clase Persona

Clase Cliente

Clase Interesado

Clase Propietario

El programa principal:

Salida por pantalla:

Descarga del código fuente: enlace a box.com


Consecuencias.

• Oculta a los clientes de la complejidad del subsistema y lo hace fácil de usar.
• Favorece un acoplamiento débil entre el subsistema y sus clientes, consiguiendo que los cambios de las clases del sistema sean transparentes a los clientes.
• Facilita la división en capas y reduce dependencias de compilación.
• No se impide el acceso a las clases del sistema.

Temas a tener en cuenta.

• Lo más importante de todo es que este patrón se debe aplicar en las clases más representativas y no en las específicas. De no ser así, posiblemente no se tenga el nivel alto deseado. 
• Por aplicación, es ideal construir no demasiados objetos Facade. Sólo algunos representativos que contengan la mayoría de las operaciones básicas de un sistema.

Es interesante el uso de este patrón, en trabajos en grupo, donde cada persona se dedica a subsistemas concretos, y los demas, si necesitan usarlos, lo usan mediante la clase "FACADE" (Fachada). En nuestro ejemplo la clase "Inmobiliaria".
Enlaces:
http://migranitodejava.blogspot.com.es/2011/06/facade.html

http://zarza.fis.usal.es/~fgarcia/docencia/poo/03-04/Trabajos/Fachada.pdf

http://powerdream5.wordpress.com/tag/facade-pattern/