Facade
JaninaVoigt (Talk | contribs) |
JaninaVoigt (Talk | contribs) |
||
Line 8: | Line 8: | ||
==Structure== | ==Structure== | ||
− | + | [[image: FacadeStructure.png]] | |
===Participants=== | ===Participants=== |
Revision as of 02:20, 26 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
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.
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 |