Patron Facade

FACADE

1. CLASIFICACIÓN DEL PATRÓN

Patrón Estructural.

2. INTENCIÓN

Proporciona una interfaz unificada a un sistema de interfaces en un subsistema. Facade define una interfaz de alto nivel que haga el subsistema más fácil utilizar.

3. MOTIVACIÓN

Estructurando un sistema en ayudas de los subsistemas reduzca la complejidad. Una meta común del diseño es reducir al mínimo la comunicación y las dependencias entre los subsistemas. Una forma para alcanzar esta meta es introducir un objeto de la fachada que proporcione una interfaz sola, simplificada a las instalaciones más generales de un subsistema.

Considere por ejemplo un ambiente de programación que dé el acceso de los usos a su subsistema del recopilador. Este subsistema contiene clases tales como explorador, el programa de análisis, ProgramNode, BytecodeStream, y ProgramNodeBuilder que ejecutan el recopilador. Algunos usos especializados pudieron necesitar tener acceso a estas clases directamente. Pero la mayoría de los clientes de un recopilador generalmente no tiene el cuidado de sobre los detalles tiene gusto de analizar y cifra la generación; quiere simplemente compilar un cierto código. Para ellos, las interfaces de gran alcance pero bajos en el subsistema del recopilador complican solamente su tarea.

Para proporcionar un interfaz de alto nivel que pueda blindar a clientes de estas clases, el subsistema del recopilador también incluye una clase del recopilador. Esta clase define un interfaz unificado a la funcionalidad del compilador. La clase del recopilador actúa como fachada: Ofrece a clientes un interfaz solo, simple al subsistema del recopilador. Pega juntas las clases que ejecutan funcionalidad del recopilador sin la ocultación de ellas totalmente. La fachada del recopilador hace vida más fácil para la mayoría de los programadores sin la ocultación de la funcionalidad de nivel inferior de pocos que la necesitan.

4. POSIBLES APLICACIONES PARA EL FACADE

Se debe usar el patrón Facade cuando:

· Se quiere proporcionar un interfaz simple a un subsistema complejo. Los subsistemas consiguen a menudo más complejos mientras que se desarrollan. La mayoría de los patrones, cuando están aplicados, dan lugar más y a clases más pequeñas. Esto hace el subsistema más reutilizable y más fácil modificar para requisitos particulares, pero también se convierte más difícilmente para utilizar para los clientes que no tienen necesidad de modificarla para requisitos particulares. Una fachada puede proporcionar una opinión simple del defecto del subsistema que es bastante bueno para la mayoría de los clientes. Solamente los clientes que necesitan más variabilidad necesitarán mirar más allá de la fachada.

· Hay muchas dependencias entre los clientes y las clases de la puesta en práctica de una abstracción. Introduzca una fachada para desemparejar el subsistema de los clientes y de otros subsistemas, de tal modo promoviendo independencia del subsistema y portabilidad.

· Se quiere acodar sus subsistemas. Utilice una fachada para definir un punto de entrada a cada nivel del subsistema. Si los subsistemas son dependientes, después usted puede simplificar las dependencias entre ellas haciéndolas comunica con uno a solamente a través de sus fachadas.

5. ESTRUCTURA

La estructura básica que maneja el Composite está compuesta por:

Fig. 1. Diagrama de clases del modelo de uso del Composite.

6. PARTICIPANTES

· Facade: sabe cuales clases de subsistema son responsables para el requisito. Delega al cliente el requisito para apropiar el subsistema de objetos.

· Subsystem clases: implementa la funcionalidad del subsistema, realiza el trabajo asignado por el objeto tipo Facade, no tiene conocimiento del facade, es decir, no mantiene referencias de este.

7. COLABORACIONES

· Los clientes comunican con el subsistema enviando peticiones a la fachada, que les transmite los objetos apropiados del subsistema. Aunque los objetos del subsistema realizan el trabajo real, la fachada pueden tener que hacer el trabajo sus los propios para traducir su interfaz a los interfaces de subsistema.

· Clientes que utilizan la fachada no deben tener acceso a sus objetos del subsistema directamente.

8. CONSECUENCIAS

El patrón Facade tiene las siguientes consecuencias:

· Blinda a clientes de los componentes de subsistema, de tal modo reduciendo el número de objetos de los cuales los clientes se ocupen y haciendo el subsistema más fácil utilizar.

· Promueve el acoplador débil entre el subsistema y sus clientes. Los componentes en un subsistema se juntan a menudo fuertemente. El acoplador débil le deja variar los componentes del subsistema sin afectar a sus clientes. Las fachadas ayudan a diseñar un sistema y las dependencias entre los objetos. Pueden eliminar dependencias complejas o circulares. Esto puede ser una consecuencia importante cuando ejecutan al cliente y el subsistema independientemente.

· No evita que los usos usen clases del subsistema si necesitan. Así usted puede elegir entre la facilidad de empleo y la generalidad.

7. IMPLEMENTACIÓN

Para la implementación del Facade es recomendable usar algunas “técnicas” para facilitar su uso.

· Reducción del acoplador del cliente-subsistema. El acoplador entre los clientes y el subsistema puede ser incluso más futuro reducido haciendo fachada una clase abstracta con las subclases concretas para diversas puestas en práctica de un subsistema. Entonces los clientes pueden comunicar con el subsistema a través del interfaz de la clase abstracta de la fachada. Este acoplador abstracto guarda a clientes de saber qué puesta en práctica de un subsistema se utiliza.

· Público contra clases privadas del subsistema. Un subsistema es análogo a una clase en que ambos tienen interfaces, y ambos encapsulan que algo-a la clase encapsula el estado y operaciones, mientras que un subsistema encapsula clases. Y apenas como es útil para pensar en el interfaz público y privado de una clase, podemos pensar en el interfaz público y privado de un subsistema.

8. CÓDIGO DE EJEMPLO

class Scanner {

public:

Scanner(istream&);

virtual ~Scanner();

virtual Token& Scan();

private:

istream& _inputStream;

};

class Parser {

public:

Parser();

virtual ~Parser();

virtual void Parse(Scanner&, ProgramNodeBuilder&);

};

class ProgramNodeBuilder {

public:

ProgramNodeBuilder();

virtual ProgramNode* NewVariable(

const char* variableName

) const;

virtual ProgramNode* NewAssignment(

ProgramNode* variable, ProgramNode* expression

) const;

virtual ProgramNode* NewReturnStatement(

ProgramNode* value

) const;

virtual ProgramNode* NewCondition(

ProgramNode* condition,

ProgramNode* truePart, ProgramNode* falsePart

) const;

// ...

ProgramNode* GetRootNode();

private:

ProgramNode* _node;

};

class ProgramNode {

public:

// program node manipulation

virtual void GetSourcePosition(int& line, int& index);

// ...

// child manipulation

virtual void Add(ProgramNode*);

virtual void Remove(ProgramNode*);

// ...

virtual void Traverse(CodeGenerator&);

protected:

ProgramNode();

};

class CodeGenerator {

public:

virtual void Visit(StatementNode*);

virtual void Visit(ExpressionNode*);

// ...

protected:

CodeGenerator(BytecodeStream&);

protected:

BytecodeStream& _output;

};

9. USOS CONOCIDOS

El ejemplo del recopilador en la sección del código de la muestra fue inspirado por Sistema del recopilador de ObjectWorks \ del palique [Par90]. En el marco del uso de ET++ [WGM88], un uso puede tener built-in herramientas de la ojeada para examinar sus objetos en run-time. Estas herramientas de la ojeada se ejecutan en un subsistema separado que incluya una clase de la fachada llamada " ProgrammingEnvironment." Esta fachada define operaciones tales como InspectObject e InspectClass para tener acceso a los hojeadores.

10. PATRONES ASOCIADOS

Se le relaciona al patrón composite frecuentemente con los patrones; abstract factory, singleton, mediator.

REFERENCIAS BIBLIOGRÁFICAS

Design Patterns. Elements of Reusable Object-Oriented Software - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides - Addison Wesley (GoF- Gang of Four)

Thinking in patterns in java – Bruce Eckel

Patterns in Java - Mark Grand – Wiley