Facade design pattern is part of the structural design patterns. Structural design patterns are the ones that are used to decide the structural architecture of the applications or the way the application layers or you can say classes are arranged. This pattern is based on one of the basic fundamental of the object oriented programming, which is encapsulation.
What is Facade design pattern ?
According to GoF’s definition, facade pattern is :
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.
A real world example :
When ever you want to withdraw some money from an ATM machine, you simply provide your input to the machine. The machine checks your input, performs the transaction at the back end (like updating your account balance), pick up the required amount of money and give you the amount that you had entered.
So overall, you make a call to the ATM machine by providing your input data and the machine does the rest and gives you the required output. So in this case, the ATM machine acts as Facade class.
Another example, a project manager assigns some task to his subordinate team lead. Team lead is responsible from getting it done from the developers and report back to the manager. So here the manager acts as the client making request for a function and the team lead acts as Facade class, responsible for getting it done from the subordinates.
Let’s get technical :
Back to our business, let’s discuss with technical concepts. A customer comes to your website, enters data for registration and then submits for the save process. In code, you could be having a process like
- Validate the username submitted & Validate the data entered – clsValidateUser
- Save the data in database after validation – clsSaveData
- Send a confirmation/welcome email to the user and re-direct the user to any page – clsSendEmails
So to implement this functionality, we could be having the situation, where we might have the calls to these classes scattered all over the code, one process here, second over there and so on (this is just a rough example to simulate the need of this pattern).
So what we could have done is create a class (lets say clsRegistrationFacade). This class will call the functions of the 3 mentioned classes. So the three processes will be wrapper into one class, which is the clsRegistrationFacade. So when the user submits the data, we will simply make a call to this class and it will perform the rest of the tasks for us. So our code structure would look like the following :
So on submission by the user, we will be simply calling the facade class and passing the data to it. So the code would look like the following :
So instead of having a scattered code, a single class takes the responsibility of the entire registration process.
One more thing before we end up, we could have used the interfaces instead of the concrete classes. This depends on your requirement that whether you require a loosely coupled architecture or not.