Design Patterns Simplified - Part 8 (Facade)

This article explains what a Facade Design Pattern is and how to use it in software development.

I am here to continue the discussion around design patterns. Today, we will go through one of the structural design patterns called Facade.

Before talking about its implementation, let’s begin by defining it.

As per GOF guys, Facade pattern is defined as:

Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.

All right! Let’s understand what they mean.

It means that when you have several sub-systems or classes, it’s often difficult for a client to interact with all of them, and if somehow the client manages to interact, the code becomes messy and difficult to maintain for any future change.

How Façade pattern works

Facade addresses the same problem by having just one interface (or wrapper class) to interact with client for all of its need. The wrapper class, internally handles all the complexity of interactions with other sub-systems.

Let’s understand this by a simple example.

We will take the same car example to illustrate the concept.

Let’s begin with building the sub-systems classes as in the following:

  1. class Body  
  2. {  
  3.     public void AssembleBody()  
  4.     {  
  5.         Console.WriteLine("Assembling Body...");  
  6.     }  
  7. }  
  9. class Engine  
  10. {  
  11.     public void AssembleEngine()  
  12.     {  
  13.         Console.WriteLine("Assembling Engine...");  
  14.     }  
  15. }  
  17. class Tyre  
  18. {  
  19.     public void AssembleTyre()  
  20.     {  
  21.         Console.WriteLine("Assembling Tyre...");  
  22.     }  
  23. }  
  25. class Accessories  
  26. {  
  27.     public void AssembleSeat()  
  28.     {  
  29.         Console.WriteLine("Assembling Seat...");  
  30.     }  
  32.     public void AssembleMusicSystem()  
  33.     {  
  34.         Console.WriteLine("Assembling Music System...");  
  35.     }  
  36. }  

So, the sub-system is built now. Now, let’s design our Facade class which will talk to the client by some public methods exposed by it.

  1. class CarFacade  
  2. {  
  3.     Body body;  
  4.     Engine engine;  
  5.     Tyre tyre;  
  6.     Accessories accessories;  
  8.     public CarFacade()  
  9.     {  
  10.         body = new Body();  
  11.         engine = new Engine();  
  12.         tyre = new Tyre();  
  13.         accessories = new Accessories();  
  14.     }  
  16.     public void AssembleCar()  
  17.     {  
  18.         Console.WriteLine("Car Assembling Started...");  
  19.         body.AssembleBody();  
  20.         engine.AssembleEngine();  
  21.         tyre.AssembleTyre();  
  22.         accessories.AssembleSeat();  
  23.         accessories.AssembleMusicSystem();  
  24.         Console.WriteLine("Car Assembling Done...");  
  25.     }  
  26. }  
In the CarFacade class, you can see that we have exposed a public method called AssembleCar to which client will have access. Internally AssembleCar is handling complexity of interactions with sub-systems like Body, Engine, etc.

Now all the required setup is ready, let’s see how client uses this.

  1. static void Main()  
  2. {  
  3.     Console.Title = "Facade pattern demo";  
  4.     CarFacade carFacade = new CarFacade();  
  5.     carFacade.AssembleCar();  
  6. }  



So as you can see that client only knows about a façade method called AssembleCar and is successfully able to assemble the car without going into the complexity of various sub-systems involved.

Class Diagram


Hope you have liked the article. Look forward for your comments/suggestions.