Facade Design Pattern

Structural Design Patterns: Facade

Today, as we make our way through the last few Structural design patterns in our extensive Guide to Software Design Patterns series, we’ll be taking a closer look at the facade design pattern. The facade design pattern is one of the simpler (and thus most commonly used) patterns we’ll come across, as it provides a simple interface that can be used to manipulate more complex logic behind the scenes, hidden from the client executor.

Throughout this article we’ll dig into the facade pattern a bit more by looking at a real world example, along with some fully-functional C# code to illustrate how the pattern can be used in your own development. Let’s get this party started!

In the Real World

The facade design pattern makes it rather easy to simplify complex processes into more abstract concepts, unbeknownst to the instigator of said processes. This practice is applied in virtually all forms of business today, but the most obvious application is in manufacturing. For example, imagine you are an executive at General Motors and you want to produce a new model of car. Your involvement in that process will be rather limited, relative to the overall complexity of releasing a new car to the world. Ultimately, you might make some top-level decisions, such as the name, style, major features, pricing, and so forth, but the actual creation of the car (and all its subsequent components) will be accomplished by thousands of other employees and departments across your company.

This is a simple example of the facade design pattern in action: The client (you, as an executive at GM in this case) makes a top-level decision about a task that is to be performed (creating a new car model). The client initiates this process with some basic inputs (name, style, price, etc), but then the majority of the grunt work is performed by more concrete worker objects (in this case, actual workers). One depertment might handle electronics, another the body shape and styling, another the engine, and so forth. As the instigating client you’ll likely perform regular checkups to see how progress is coming along, but these updates will typically be abstract notions rather than highly-detailed specifics. The Head of Electronics might indicate that 80% of the work is complete, but an extra two weeks are required. The specifics of what exactly is going on with the electronics — which components are working and which need to be redesigned — will often be irrelevant to you, as the client that began the process of creating a new model.

These concepts bleed into nearly every aspect of business, but that’s a relatively common (and simple) real world example of the facade design pattern being put to good use.

How It Works In Code

For facade design pattern code example we’ll be sticking with one of my favorite topics: books. In this case, our client wants to check if a particular book is ready to be published, but the client doesn’t want to concern him or herself with the specific status of each component involved in publication (author, content, editor, publisher, cover, and so forth). The client just wants an easy way to determine if a particular book is ready to be published or not, so this is a perfect scenario in which to implement a facade pattern.

As is often the case, we’ll start with the full working code example right away, and afterward we’ll go over it in more detail to see how the facade design pattern is implemented:

The facade design pattern is intended to simplify the behavior of many sub-components that are required to create a larger, more abstract concept. Therefore, in the case of publishing a book we start with a series of classes that all perform a unique role in creating the completed work:

We have five component classes that we’ll be using here. As you can see, Author and Content include a few constructor overloads to allow for population of the Name and Title properties, respectively. Otherwise, all five of these component classes are quite basic, simply implementing a HasClassName() method that returns a boolean indicating if the passed in book parameter meets the requirements of that class. For Cover.HasCover() and the like, this method merely checks for the existence of the Cover property associated with the book parameter. Author, on the other hand, also verifies that the Author has a Name.

Again, the logic of these component classes can be expanded as much as necessary, but the basic principles still apply. We’re able to use all of these classes, along with their internal logic, and in tandem with a facade of some sort, to determine if a book is ready to be published.

We next need to define our Book class, which each of our component classes expects as a passed parameter:

Nothing too fancy going on here. Just to simplify things we’re keeping track of public properties of each of our component classes within the Book class, which can be easily populated with one of the constructor overloads. That said, we’re not performing any logic about the Book instance or its readiness for publishing within this class, because we want to handle that via a facade if some sort. As it happens, we’ll handle that facade right now with our final definition, the BookFacade class:

Here we’ve decided to use internal properties for each of our component classes (along with initial instances as their default values). This ensures that we can use instances of these components within our BookFacade logic, without exposing them to outside clients or other objects.

Our entire facade design pattern example here boils down to the BookFacade.IsPublishable(Book book) method, which checks that every component class returns a positive (true) value for their respective HasClassName() method call. Thus, a client only needs to call IsPublishable() with a passed in Book instance to determine if all the underlying component logic is valid or not.

To put this into action we have two book instances we’ve created:

We start by instantiating a new BookFacade object, then move onto creating an empty Book object, before outputting the content of emptyBook and the status of the bookFacade.IsPublishable() method result. As we should expect, since a completely empty Book instance doesn’t contain any of the requisite component property instances, emptyBook isn’t publishable:

We’ve also created a second Book instance called populatedBook, and passed in new instances of all the component classes. This should populate all the required properties of populatedBook, giving us a positive result from the IsPublishable(). Sure enough, it works!

This is just a small taste of what can be accomplished with the facade design pattern, but I hope it gave you a bit more insight into the simplicity and potential power it can provide. Check out more design patterns in our ongoing series over here!