Facade Design Pattern

Facade by itself is pretty simple pattern, and there should be no confusion around it. Basically, in case you want to add some layer of abstraction for the client using your interface, you might want to use Facade.

Let us take a look into a pretty common scenario – customer registration. Customer registration by itself is both common and pretty complex scenario in case you want to get it right. When trying to implement such system, you always have to think about user data validation, getting that data, and then decide how this data is going to be stored. Given different business scenarios, even more parts might come in place. So, it is mostly always the problem when this system is implemented, and someone needs to provide customer registration somewhere else or just might need to reuse an existing logic.

So, Facade in such scenarios might be pretty common. In my own experience, I have used Facade when implementing Licensing System of the software being developed, since License Changes for the current user can be applied from lots of places, and licensing itself contains lots of possible scenarios which must be covered in order to make sure that license is applied for the user that has really bought that license, not some fraud.

Now, I will show you a code sample of how the Facade can be implemented. Your implementation is going to be different probably, and this is completely fine, since your scenario might also be different than this example. Below is the code in C# how Facade can be implemented for simple customer registration:

// This interface is responsible for getting field values (e.g. HTML fields in a web form).
public interface IUserDataReader
{
    string GetFieldValue(string name);
}
 
// This interface is responsible for validating customer data entered
public interface ICustomerDataValidator
{
    bool EmailIsValid(string email);
 
    bool PasswordIsValid(string password);
}
 
// Then, this is the storage point of the new customer
public interface ICustomerRepository
{
    void AddCustomer(string email, string password);
}
 
// There is our Facade interface we are going to give to our clients.
public interface ICustomerRegistrationFacade
{
    bool RegisterNewCustomer();
}
 
/*
And finally, there is our package-private Facade we are not going to share with other clients.
Instead, we might give clients some factory or something else to get the instance of facade interface.
Of course, this example is pretty simplified, but it clearly shows that this is the point where all dependencies are swallowed.
*/
class CustomerRegistrationFacade
    :  ICustomerRegistrationFacade
{
    private readonly ICustomerDataValidator _validator;
    private readonly IUserDataReader _userDataReader;
    private readonly ICustomerRepository _repository;
 
    CustomerRegistrationFacade(ICustomerDataValidator validator, IUserDataReader userDataReader, ICustomerRepository repository)
    {
        _validator = validator;
        _userDataReader = userDataReader;
        _repository = repository;
    }
 
    public bool RegisterNewCustomer()
    {
        var email = _userDataReader.GetFieldValue("email");
        var password = _userDataReader.GetFieldValue("password");
 
        if (!_validator.EmailIsValid(email))
            return false;
 
        if (!_validator.PasswordIsValid(password))
            return false;
 
        _repository.AddCustomer(email, password);
 
        return true;
    }
}

Usage of such Facade can be very simple for the client, since client has no need to think about validation, getting the data, and storing it somewhere else.

if (!facade.RegisterNewCustomer())
    // Return some error.
// Do something else, since new customer is added.

As it can be seen, Facade is a good pattern in case you want to add some layer of abstraction, and restrict sharing of concerns to the client in some package. Instead, your goal is to give functionality to the client that client actually needs instead of making him/her/it worrying about more than it is required.

Finally, you can see more information regarding Facade Design Pattern here (these sources explain it pretty well, too):

  1. https://en.wikipedia.org/wiki/Facade_pattern
  2. https://www.geeksforgeeks.org/facade-design-pattern-introduction/
  3. https://www.tutorialspoint.com/design_pattern/facade_pattern.htm
  4. https://sourcemaking.com/design_patterns/facade

Leave a Reply

Your email address will not be published. Required fields are marked *