- Overview
- Introducing the Facade Pattern
- Learning the Facade Pattern
- Field Notes: The Facade Pattern
- Relating the Facade Pattern to the CAD/CAM Problem
- Summary
- Review Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Field Notes: The Facade Pattern
Facades can be used not only to create a simpler interface in terms of method calls, but also to reduce the number of objects that a client object must deal with. For example, suppose I have a Client object that must deal with Databases, Models, and Elements. The Client must first open the Database and get a Model. Then it queries the Model to get an Element. Finally, it asks the Element for information. It might be a lot easier to create a Database Facade that could be queried by the Client (see Figure 6-4).
)
Figure
6-4 Facade reduces the number of objects for the client.
Variations on Facade: Reduce the number of objects a client must work with
If a Facade can be made to be stateless (that is, no state is stored in it), one Facade object can be used by several other objects. Later, in Chapter 21, I show you how to do this, using the Singleton pattern and the Double-Checked Locking pattern.
Having one Facade work for many objects
Suppose that in addition to using functions that are in the system, I also need to provide some new functionality—say, record all calls to specific routines. In this case, I am going beyond a simple subset of the system.
Variations on Facade: Supplement existing functions with new routines
In this case, the methods I write for the Facade class may be supplemented by new routines for the new functionality. This is still the Facade pattern, but expanded with new functionality. I consider the primary goal one of simplification because I don't want to have to force the client routine to know that it needs to call the extra routines—the Facade does that.
The Facade pattern sets the general approach; it got me started. The Facade part of the pattern is the fact that I am creating a new interface for the client to use instead of the existing system's interface. I can do this because the Client object does not need to use all of the functions in my original system.
Patterns Set a General Approach
A pattern just sets the general approach. Whether or not to add new functionality depends upon the situation at hand. Patterns are blueprints to get you started; they are not carved in stone.
The Facade can also be used to hide, or encapsulate, the system. The Facade could contain the system as private members of the Facade class. In this case, the original system would be linked in with the Facade class, but not presented to users of the Facade class.
Variations on Facade: An "encapsulating" layer
There are a number of reasons to encapsulate the system, including the following:
Track system usage—By forcing all accesses to the system to go through the Facade, I can easily monitor system usage.
Swap out systems—I may need to switch systems in the future. By making the original system a private member of the Facade class, I can swap out the system for a new one with minimal effort. There may still be a significant amount of effort required, but at least I will only have to change the code in one place (the Facade class).