Facade Design Pattern

Facade Design Pattern is one of the simplest design patterns that is used frequently in software design. As per Wikipedia, the word ‘Facade’ is derived from the building architecture term Facade which is one exterior side of a building. This is the “interface” to the building. In the same way, a Facade is an interface to a larger body of code. More details are available at this Wikipedia link.

Please check out my new video on the Facade Design Pattern.

This video provides a simple example from real life where an individual acts like a “Facade”. A surveyor has a questionnaire that needs the following information:
1. Age Range of the person filling the survey
2. Income Range of the person filling the survey
3. Name of their favorite cafe in the city.

Lets assume that the person who wants to conduct this survey needs to visit an office building and collect this information from all the employees working in that building. One way to do this would be to speak to each employee and collect this data. This is, of course, assuming they will allow the survey person to speak to each employee. Another option is to speak to the location supervisor and hand over these survey to that person. The supervisor would talk to each employee, collect this information and hand over the responses on a stack of paper or electronic document to the survey person. This greatly simplifies the interaction between the survey person and the employees in that building. And in this case, the supervisor is the ‘facade’ to the employees in the building. Please note that the total number of interactions for data collection does not change but the interface between the survey person and the the employees is certainly simplified. This is application of the “Facade” pattern in terms of human interaction.

If we extend this model to software design, we could consider this scenario as an example. We have a class library called GeographicalServicesLibrary. The purpose of this library is to provide the distance between two addresses. This class library consists of the following classes:

a. Address Validator – This class exposes a solitary method that takes an address as a string parameter and returns a properly formatted address (format defined by postal service) to the caller. If the address is invalid, the returned string would contain an error code.

b. Geocode Helper – This class exposes a method that takes a properly formatted address and returns a Point object that contains the coordinates of that address (latitude and longitude).

c. Distance Calculator – This class provides a method that calculates the distance between two Point objects.

In order to calculate the distance between two addresses, the client object has to perform the following calls to this class library:

i. Call the Address Validator method and validate the first address.

ii. Call the Address Validator method and validate the second address.

iii. Call the Geocode Helper method and get the coordinates of the first address.

iv. Call the Geocode Helper method and get the coordinates of the second address.

v. Call Distance Calculator method and pass the coordinates of the two addresses and get the distance between the two coordinates.

This is shown in the c# code below:

//validate the first address
String ValidatedAddress1 = AddressValidatorObject.ValidateAddress(Address1);
//validate the second address
String ValidatedAddress2 = AddressValidatorObject.ValidateAddress(Address2);
//get the coordinates of the first address
Point p1 = GeocodeHelperObject.GetGeoCode(ValidatedAddress1);
//get the coordinates of the second address
Point p2 = GeocodeHelperObject.GetGeoCode(ValidatedAddress2);
//calculate the distance between the two addresses
Double Distance = DistanceCalculatorObject.GetDistance(p1, p2);

The total number of interactions between the client object and the class library members can be significantly reduced by introducing a “facade” object called the Geographical Service Facade. This class could expose a method that would take the two addresses as input parameters and return the distance between the two addresses. This facade object could interact with the members of this class library to get the desired output (distance between two addresses). The Facade class reduces the dependencies between the client and the class library members because only one class (the Facade) has dependencies on the class library. This is specially important if the class library is a third party library that may get replaced later. If a replacement is needed, only the one call in the Facade needs to change.

This is shown in the c# code below:

//calculate the distance between two addresses
Double Distance = 
GeographicalServicesFacadeObject.CalculateDistance(Address1, Address2)

Also, you could argue that the class library was poorly designed. If the goal of the class Library is the return the distance between two addresses, all it had to do was to keep expose this functionality perhaps as a Facade object. And the library could hide the three classes – Address Validator, Geocode Helper and Distance Calculator. This brings forward another advantage of the Facade Pattern that it simplifies interactions with a poorly designed library. In general, Facade Pattern makes a library or any collection of components easy to use and test. This is because the interface to the components is greatly simplified due to the introduction of the Facade object. Please note that Facade does not necessarily has to hide a large collection of components or a class library. It could just be introduced to simply interactions among any collection of objects.

Thanks for visiting this site and reading this post. Hope you liked the explanation. I’d love to get your feedback on this post and also your experience with the Facade Design Pattern.