by andrew

Design patterns: facade

The adapter pattern mentioned in previous post was only one of two design patterns mentioned in seventh chapter in the book. When you continue the reading you’ll find interesting discussion between a decorator and an adapter. It leads to the conclusion that both of these two design patterns seem to look similar on a paper but they are different in their intent. The end of this discussion as well as introduction to facade pattern is a simple table:

Pattern

Intent

Decorator

Converts one interface to another

Adapter

Doesn’t alter the interface but adds responsibility

Facade

Makes an interface simple

Book example

Before we learn the definition and schema of facade pattern we read about another real life example. It’s connected to the obsession some of us or our friends had: building a home theater. Usually it made of many of different components:

Many components of a home theater system

If you want to watch a movie there is few-steps procedure to set all the components of your home theater. Once you’ve done it you’re already tired. If you manage and finish the movie you have to repeat all the steps in reverse. Listening to a CD or a radio isn’t easier either. And things are getting more complex when you want to add new components. Facade pattern is the right design pattern to help you!

A home theater system with facade pattern used

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

An example application can be downloaded as usual. Feel free to play with it However, it’s not the end of the chapter. The facade design pattern not only makes an interface simplier for a client but also helps us obligate to another OO principle. The principle of Least Knowledge as known as Law of Demeter: talk only to your immediate friends. It means when you’re designing an application, for any object, be careful of the number of classes it interacts with and also how it comes to interact with those classes. It prevents us from creating systems with a large number of classes coupled together so that changes in one part of the system cascade to other its parts. When you don’t apply this principle you’re probably creating fragile applications that will be costly to maintain and complex for others to understand. To make it easier you can take any object and then from any method in that object, the principle tells us that we should only invoke method that belong to:

the object itself,

objects pass in as a parameter to the method,

any object that methods creates or instantiates,

any components of the object (objects that are referenced by an instance variables).

The facade pattern is really helpful for us if we want to apply The Principle of Least Knowledge in our bigger systems. We can tell it just by looking at its diagram:

An example of how usage of facade pattern helps obey the principle of least knowledge

The client is coupled only with the facade which makes the client simple and flexible. Changes in any of subsystem’s classes don’t affect the client.

There weren’t any code snippets presented in the post content but as always you can download some code examples and take a look at them.