May 12, 2011

Design Patterns Simplified: The Facade Pattern


The Facade design pattern is one that is used throughout the software world as a way to make interacting with complex system APIs simpler. A facade class is one that encapsulates part or all of the public APIs of several system classes as its public API; the result is that one only has to deal with a single API, that of the facade, rather than the APIs of many classes. Sound complex? Hopefully not. But just in case you're still a little bit fuzzy, we'll start with a real-world example.

A Real-World Facade Pattern Example

Whether you realize it or not, you probably encounter examples of the facade pattern in your everyday interactions quite often. Take, for example, a visit to your favorite table service restaurant. Once you are seated, your waiter takes your beverage order and brings it to the bar. The bartender reads your order and makes your drinks. When the bartender has made your drinks, she alerts the waiter who retrieves them from the bar and brings them to you. In similar fashion, the waiter takes your dinner order and brings it to the kitchen. The kitchen staff reads your order and makes your meal. When the kitchen staff has made your meal, it alerts the waiter who retrieves it from the kitchen and brings it to you. In the event that a particular dish that you ordered is no longer available, the kitchen staff informs the waiter who in turn informs you and requests a different order from you.

You see, you interact with your waiter by placing your order, and he interacts with the rest of the restaurant staff on your behalf. If this were not the case, you'd be responsible for ordering your drinks directly from the bartender, listening for the bartender to tell you that your drinks are ready, then retrieving your drink order from the bar; the case for your dinner order and the kitchen staff would be quite similar. In this way, the waiter is the facade between you and the inner workings of the restaurant.

The Facade Pattern in Everyday Technology

You may also not realize that you see the facade pattern in your everyday interactions with technology. If you're a working stiff like I am, chances are you interact with an Enterprise Resource Planning application that manages requests for time off, benefits administration, performance reviews, departmental metrics, etc. If you're a student, you likely interact with a similar application that manages your course registration, grades, transcript requests, graduation application, financial aid, etc. In either the professional or academic case, the application you interact with is a facade that coordinates the transactions among the different underlying systems for each domain. This facade implementation allows you to interact with the different systems responsible for managing time off, benefits, course registration, or financial aid through a single interface rather than through separate interfaces for each system.

The Facade Pattern in Software Design

The facade pattern is used extensively in software design. Public APIs for web applications and services such as Twitter provide a facade for developers to interact with the internals of the system. However, before attempting to use the Facade Pattern in the design of your application you should make sure that it is appropriate to do so. There is nothing worse for a developer than having to maintain an application that has been shoe-horned into a particular design pattern. Here are some check points to make sure that the Facade Pattern is right for your case:

  • Do you have a set of related classes?
  • Do you frequently perform the same operations with these classes in your code?
  • Would adding a facade class reduce the complexity of working with these classes?
While the list above is not exhaustive, it should point you in the right direction. Here is an example UML class diagram for an implementation of the Facade Pattern:

As you can see, the MyFacade class is composed of instances of MyClassFoo and MyClassBar, and we can assume that the method doSomethingWithFooAndBar is one that will incorporate the use of both of the composed classes. Here is a look at some sample code for this facade implementation, written in C#:

So now you've seen what the Facade Pattern looks like in everyday life, technology, and software design. But, if you're not quite ready to run out and use it, or if you just want to get some more background on the Facade Pattern or design patterns in general, feel free to take a gander at the reading list below.

Further Reading

See below for further reading to help you understand the Facade Pattern and its use in application code.

Design Patterns: Elements of Reusable Object-Oriented Software
Design Patterns Explained: A New Perspective on Object-Oriented Design (2nd Edition)
Facade pattern (Wikipedia)
C# Design Patterns - The Facade Pattern (GeekDaily)
Facade Clears Complexity (JavaWorld)
Introducing the Facade Pattern in PHP 5 (DevShed)

Talk to me, Goose

I love getting feedback. No, really, I do. Feel free to leave comments or questions below or email me at brian at brian-driscoll dot com.

1 comment:

Tyler Jensen said...

One potential drawback to the facade pattern is the law of unintended consequences. To take the example of the waiter where the kitchen may change its behavior but the waiter's behavior does not change. In other words, the dependency the facade has on its constituent parts must be taken into account. Following good SOLID principles will help with this in that the class upon which the facade relies should have only one reason to change.