Facade
From CSSEMediaWiki
(Difference between revisions)
JaninaVoigt (Talk | contribs) |
JaninaVoigt (Talk | contribs) |
||
| 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== | ==Structure== | ||
| Line 12: | Line 17: | ||
* Clients communicate with the subsystem through the facade and don't have access to the subsystem objects directly. | * 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 | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ==Consequences== | |
| − | * provides | + | * 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. | ||
| − | == | + | ==See Also== |
| − | + | *[[Design patterns]] | |
[[Category:Design Patterns]] | [[Category:Design Patterns]] | ||
Revision as of 07:51, 24 July 2009
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
TODO: add UML diagram
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
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.
See Also
| Design patterns | |
|---|---|
|
Creational: Abstract Factory | Builder | Factory Method | Prototype | Singleton | |
