Facade
From CSSEMediaWiki
(Difference between revisions)
(more descriptions and an example) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Mujtaba Alshakhouri) |
||
| (9 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
The facade pattern is used to provide a simple interface to a complex set of interfaces. Often facades are produced to further simplify common APIs or adapt them to a more specific use. | The facade pattern is used to provide a simple interface to a complex set of interfaces. Often facades are produced to further simplify common APIs or adapt them to a more specific use. | ||
| − | + | ==Use When== | |
| − | * | + | * You want to provide a simple interface to a complex subsystem. |
| − | * | + | * Clients are closely coupled with the implementation of an abstraction. Use Facade to decouple clients from the implementation. |
| − | * | + | * You want to layer subsystems. Create a Facade for each subsystem level as an access point and get the subsystems to communicate with each other through their facades. |
| + | |||
| + | ==Structure== | ||
| + | |||
| + | [[image: FacadeStructure.png]] | ||
| + | |||
| + | ===Participants=== | ||
| + | * Facade: The Facade knows the internal workings of the subsystem and which classes have which responsibilities. It delegates client request to the correct part of the subsystem. | ||
| + | * Subsystem classes: These classes implement the functionality of the subsystem and handle work assigned to them by the facade. However, they are unaware of the existence of the facade. | ||
| + | |||
| + | ===Collaborations=== | ||
| + | * Clients communicate with the subsystem through the facade and don't have access to the subsystem objects directly. | ||
== Example == | == Example == | ||
The boot process of a computer can be modeled as a Facade. The system's boot() method is called. This method now starts and configures all the services and programs needed to use the computer. | The boot process of a computer can be modeled as a Facade. The system's boot() method is called. This method now starts and configures all the services and programs needed to use the computer. | ||
| + | |||
| + | TODO: add UML diagram and explain the example in more detail | ||
| + | |||
| + | Another simple example is checking if the customer is eligible for a mortgage. Client app consults Mortgage class whether the customer is able to get the mortgage. Mortgage class talks to the subsystems to check his loan, his level of savings and credit history. | ||
| + | |||
| + | [[image:Facade.PNG]] | ||
| + | |||
| + | |||
| + | === Another Example === | ||
| + | You can find [http://java.dzone.com/articles/design-patterns-uncovered-1 here] a nicely explained java code example of the Facade Pattern usage in the real world. | ||
| + | |||
| + | ==Consequences== | ||
| + | * The facade makes subsystems easier to use because it provides a simple interface, meaning that clients do not need to access and understand subsystem objects. | ||
| + | * It decouples the subsystem from its clients, meaning that the subsystem can be modified without affecting clients. | ||
| + | * Can be too general as it doesn't prevent any applications from using subsystem classes. | ||
| + | * Can turn a badly designed API into a very usable one. | ||
| + | |||
| + | ==Related Patterns== | ||
| + | * [[Abstract Factory]]: This pattern can be used with Facade to create subsystem objects in a subsystem-independent way. | ||
| + | * [[Mediator]]: This pattern is similar to Facade in that it attempts to abstract communications between objects. However, these objects are aware of the fact that they are communicating with a Mediator instead of each other, while subsystem classes in a Facade design pattern are unaware of the Facade. | ||
| + | *[[Singleton]]: This pattern is often used because only one Facade object is needed most of the time. | ||
| + | |||
| + | ==See Also== | ||
| + | *[[Design patterns]] | ||
[[Category:Design Patterns]] | [[Category:Design Patterns]] | ||
[[Category:Structural Patterns]] | [[Category:Structural Patterns]] | ||
| + | [[Category:Pages that need examples]] | ||
{{design patterns}} | {{design patterns}} | ||
Latest revision as of 03:22, 25 November 2010
The facade pattern is used to provide a simple interface to a complex set of interfaces. Often facades are produced to further simplify common APIs or adapt them to a more specific use.
Contents |
Use When
- You want to provide a simple interface to a complex subsystem.
- Clients are closely coupled with the implementation of an abstraction. Use Facade to decouple clients from the implementation.
- You want to layer subsystems. Create a Facade for each subsystem level as an access point and get the subsystems to communicate with each other through their facades.
Structure
Participants
- Facade: The Facade knows the internal workings of the subsystem and which classes have which responsibilities. It delegates client request to the correct part of the subsystem.
- Subsystem classes: These classes implement the functionality of the subsystem and handle work assigned to them by the facade. However, they are unaware of the existence of the facade.
Collaborations
- Clients communicate with the subsystem through the facade and don't have access to the subsystem objects directly.
Example
The boot process of a computer can be modeled as a Facade. The system's boot() method is called. This method now starts and configures all the services and programs needed to use the computer.
TODO: add UML diagram and explain the example in more detail
Another simple example is checking if the customer is eligible for a mortgage. Client app consults Mortgage class whether the customer is able to get the mortgage. Mortgage class talks to the subsystems to check his loan, his level of savings and credit history.
Another Example
You can find here a nicely explained java code example of the Facade Pattern usage in the real world.
Consequences
- The facade makes subsystems easier to use because it provides a simple interface, meaning that clients do not need to access and understand subsystem objects.
- It decouples the subsystem from its clients, meaning that the subsystem can be modified without affecting clients.
- Can be too general as it doesn't prevent any applications from using subsystem classes.
- Can turn a badly designed API into a very usable one.
Related Patterns
- Abstract Factory: This pattern can be used with Facade to create subsystem objects in a subsystem-independent way.
- Mediator: This pattern is similar to Facade in that it attempts to abstract communications between objects. However, these objects are aware of the fact that they are communicating with a Mediator instead of each other, while subsystem classes in a Facade design pattern are unaware of the Facade.
- Singleton: This pattern is often used because only one Facade object is needed most of the time.
See Also
| Design patterns | |
|---|---|
|
Creational: Abstract Factory | Builder | Factory Method | Prototype | Singleton | |
