«

»

Aug 31

Print this Post

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:

a home theater system class hierarchy

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 a facade class on the top

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:

client and facade design pattern in terms of the principle of least knowledge

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.

Other examples

Basically, there are as many real examples of facade pattern usage as complex systems. Asking Google for “php facade pattern example” or “php facade pattern real example” results with hundreds of thousands links. From simple array-string operations repeated on few pages, more real-life examples with simplifying books’ borrowing to more “backend-ish” solutions such as: creating template mechanism with caching to a Zend service for SlideShare. The last one is particularly interesting when there are more and more SOA around us ;)

Other design patterns

Here is the list of described by me design patterns:

Permanent link to this article: http://blog.lukaszewski.it/2013/08/31/design-patterns-facade/

1 comment

  1. Grace

    Thank you for this. I’m new to programming and enjoy when examples are relatable like this, as I can make more sense of them without having the barrier of prior knowledge getting in the way.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>