What are Design Patterns?
Most of you already know what a design pattern is, but I want to make sure this blog is accessible to everyone. A design pattern is a set of “best practices” for how to structure your code to solve certain problems. It is not a completed library that you an plug in to your code base, but more like a template helping you determine how to structure the code you are writing.
There are a couple of good books out there describing Design Patterns. The one most people will point you to is the Gang of Four (Design Patterns: Elements of Reusable Object-oriented Software) book. I know it is probably blasphemy to admit, but I have actually not read that one…I have, however, read the Head First Design Patterns book and I highly recommend it.
Today we are going to dive into the Facade pattern.
The definition of the word facade helps me remember what this pattern is used for:
- an outward appearance that is maintained to conceal a less pleasant or creditable reality.
We often use the facade pattern to hide either a complex part of the system (or subsystem) or to simplify the use of some subsystem. And, sometimes we use it to simply hide a subsystem, third-party library, etc.
It is obvious why we want to create a class that understands the complexity of a subsystem and keep that complexity out of the other parts of your code. However, it is probably less obvious why you would want to simply hide a subsystem or third-party library behind a facade.
If you hide your subsystem, or third-party library behind a facade, it will allow you to more easily switch this system out for a new one, or even a new version without having to do major refactoring. If there is only one place that is dealing with this system, there is only one place where you need to make changes.
Secondly, using a facade can help you to mock out systems that you interact with for testing. Sometimes it can be difficult to fake out a system you are interacting with, but if every part of your system uses the facade, then you simply have to mock out the facade in the rest of the application, and only worry about figuring out how to mock the real system out for the tests around the facade.
Lastly, when you hide things behind a facade it allows you to delay making major architectural decisions. You can determine what you want the API to this system to look like, and even fake out the interactions until you have had a chance to decide how you want to implement the subsystem.