GoF define Façades intent as “Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higherlevel interface that makes the subsystem easier to use”.
A good way to remember Façade is to imagine a sub system that is badly designed or complex or legacy system. In all the cases there might be a need to reuse the system because of some reason or the other. You know sometimes we do get to work in a project which needs to interact with one of these types of system. Now in order to interact with this sub system we might need an interface which is let's say more clean and is OO in nature so that the system we are developing understands it better than the sub system. Therefore, the need is clear. We have to interact with a sub system but it is not of our taste because of many reasons and hence we need to develop and interface which the system we are developing understands more easily. This interface would be the Façade While talking about the Adapter pattern we mentioned that remembering the intent of the pattern is not so difficult if we can also associate it with a real world example. Here is one which fits Façade quite well.
The best hotel in the world where I have stayed so far is Grand Hayyt in Tokyo. It had everything – a view to die for, service extraordinary. While googling I realised that folks are using a Hotel's front desk (reception) as a Façade example and it did not take long for me to understand why. Grand Hayyt Tokyo, where everything was dial “9” away. Yes, call the reception and you get what you want. Imagine this scenario – let's assume that you are in mood to go for a dinner in the best French restaurant in Tokyo and if you don't get a dinner reservation there then probably the best Japanese restaurant in the town. After dinner you would like to go for a movie and then finally have a special Kenyan coffee in your hotel room. You just need to dial “9” and tell all this to the reception. They will just arrange everything for you. But in order to arrange a taxi which would drop and pickup with an english speaking driver and then to get you the tickets of a movie booked and then finally dropping the guest back to the hotel and preparing that rare coffee maybe in the middle of the night and finally delivering it to the guest in the room is one big massive exercise. All this would need the hotel reception to interact with complex sub systems like taxi booking service and movie booking service and their own coffee shop and get all this in order. The complex sub system is hidden from the client and the client only dials “9”. So who is the façade here ? The number “9” !However it's important to remember that I as a client might not need all the sub systems all the time. I might just need a few of them. Below is the diagram from GoF which represents a Façade -
Clearly Façade provides an interface between the complex sub system and client classes, that is
something that you were developing.
Let's Dive Deep
How to understand that there is a need to use Façade in our design ?It's time we talk about how we can recognize that there is a need of a Façade pattern during SDLC ? One way to do this is to understand the requirements at the Design phase. At the design phase if you feel that there is a need to talk to an existing system by multiple people and if all these people don't need all of the underlying sub system but some of it then there is a fair possibility of using a Façade
Façade and Encapsulation
By now you must have realized that Façade can totally encapsulate a sub system from the client. But this might not be the case, always. There are certain situations where the client might want to talk to a sub system directly without going through the Façade These type of behaviour is not very usual but might be required at times. Considering our five star hotel example above, if a client needs to go and do a currency exchange, I don't think the entire currency exchange counter is going to come to my room. It is required to go to the exchange counter and submit the passport and fill a small form and then you can get your currency. So there are some instances where the client might have to interact with the underlying sub system directly. These needs are not very frequent and sometimes unusual (in this case currency exchange is not very unusual tho).There is a situation where the underlying sub system can be made completely encapsulated. So the end user will need to go through the Façade to reach the underlying system. There are no exceptions. No unusual case. In this scenario the entire sub system becomes swappable at some point of time if there is a need to do so. Finally here is one more diagram of Façade from GoF
1) GoF – Gang of Four
Comments are closed for this blog post