Time for another, simple, design pattern. The Facade Pattern.

I'm going to need a break soon, getting a bit burned out, which never is a good thing.

Anyway, the definition of today's pattern: "Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use."

The hardest part of writing articles for this series isn't so much understanding the patterns itself, but coming up with examples with somewhat make sense in my gaming example. So, please forgive me if they sometimes are a bit far fetched, like today ;)

Let's say we have some complex subsystem which handles everything about storage. Some classes for our CD drive, some for our hard disk, memory and much more.

If we need to load a new map, one way to do it would be to load up the cd, copy it to the hd, load it into memory and stop the cd from spinning.

Or, we could also create a new class, which defines some more high-level operations such as LoadMap(), which takes care of dealing with the subsystem.

This way, our clients can use a simple interface, but if they really need to, can still go straight to the subsystem classes themselves, as opposed to the Adapter Pattern, where you only talked to the Adapter.

And that's it really, Facade and Adapter are very alike, and both very simple.

Let's have a look at the full diagram, and image the subsystem contains a lot more classes than I drew :)

Time to test it and have our client use the StorageFacade directly, instead of the subsystem.

I've uploaded the solution again, worth a look.

In my opinion, the Facade Pattern is a helper pattern to make your code easier to use and more user-friendly, other developers being the user.

Some additional information on the Facade Pattern:

• Wikipedia - Facade Pattern.
• Data & Object Factory - Facade Pattern Overview.