This chapter is from the book
This chapter is from the book
This chapter is from the book
Learning the Facade Pattern
Once, I worked as a contractor for a large engineering and manufacturing company. My first day on the job, the technical lead of the project was not in. Now, this client did not want to pay me by the hour and not have anything for me to do. They wanted me to be doing something, even if it was not useful! Haven't you had days like this?
A motivating example: Learn how to use our complex system!
So, one of the project members found something for me to do. She said, "You are going to have to learn the CAD/CAM system we use some time, so you might as well start now. Start with these manuals over here." Then she took me to the set of documentation. I am not making this up: There were 8 feet of manuals for me to read—each page 8.5 x 11 inches and in small print! This was one complex system!
)
Figure
6-1 Eight feet of manuals = one complex system!
Now, if you and I and say another four or five people were on a project that needed to use this system, what approach would we take? Would we all learn the system? Or would we draw straws and the loser would have to write routines that the rest of us would use to interface with the system?
I want to be insulated from this
This person would determine how I and others on our team were going to use the system and what application programming interface (API) would be best for our particular needs. She would then create a new class or classes that had the interface we required. Then I and the rest of the programming community could use this new interface without having to learn the entire complicated system (see Figure 6-2).
)
Figure
6-2 Insulating clients from the subsystem.
This approach works only when using a subset of the system's capabilities or when interacting with it in a particular way. If everything in the system needs to be used, the only way to improve the design would be if it were poor in the first place.
Works with subsets
This is the Facade pattern. It enables us to use a complex system more easily, either to use just a subset of the system or use the system in a particular way. We have a complicated system of which we need to use only a part. We end up with a simpler, easier-to-use system or one that is customized to our needs.
This is the Facade pattern
Most of the work still needs to be done by the underlying system. The Facade provides a collection of easier-to-understand methods. These methods use the underlying system to implement the newly defined functions.
The Facade Pattern: Key Features
|
Intent |
You want to simplify how to use an existing system. You need to define your own interface. |
|
Problem |
You need to use only a subset of a complex system. Or you need to interact with the system in a particular way. |
|
Solution |
The Facade presents a new interface for the client of the existing system to use. |
|
Participants and collaborators |
It presents a simplified interface to the client that makes it easier to use. |
|
Consequences |
The Facade simplifies the use of the required subsystem. However, because the Facade is not complete, certain functionality may be unavailable to the client. |
|
Implementation |
Define a new class (or classes) that has the required interface. |
|
|
Have this new class use the existing system. |
)
Figure
6-3 Generic structure of the Facade pattern.