Facade design pattern. What is it and why is it useful?

One of the most common patterns in software development is the facade pattern, but what really is a facade, and why is it useful?

What is a Facade?

Let's take a waiter at a restaurant for example. You give the waiter a list of meals and drinks you would like to order, and then they just take care of everything else while you chill and enjoy good company.

They write down your order (or memorize it), then input it into a POS, which sends the request to the kitchen with the relevant table number and order information.

The chef(s) meticulously prepare your order, they use grillers, ovens, various other tools, and that special secret sauce to craft a mouth-watering scrumptious meal (dam it must be dinner time 😋, anyway...).

You're at this restaurant to have a good time and enjoy your meal. You don't care about the process, so long as it's safely prepared, and delicious.

A Facade is like that waiter. It's a class that provides a simple interface, hiding complex logic, and orchestrating various objects in the background in a seamless way, keeping your implementation code clean and concise.

Let's look at a practical code example:

db.insert({"name": "kevin"});

Under the hood:

1. We are invoking some kind of ORM that translates the dictionary into an SQL insert statement.
2. There is query binding that safely handles the user input string "kevin" to prevent SQL injection.
3. Various network processes happen to transmit IP packets of data from the code to the actual DB server and back.
4. The list goes on... At each of these stages, multiple classes and functions are being brought into play to achieve the desired result, a bit like an assembly line.

How many times do you insert data into the DB throughout your web app? Countless, just imagine this one line being 20. What a pain!

Facades solve this problem and lead to much cleaner code.

Some bad side effects of facades

Generally, facades are great, they help you write much cleaner code and organize your code better, but like with everything else in life, there are some negative side effects to be aware of:

• Performance implications: Taking the DB facade from my earlier example, if you are inserting one billion rows into the DB using an interpreted language like Python, it might just be more performant to write SQL directly and manually manage the DB connection.
• Compatibility issues: You need to have good unit tests and trust in the maintainer. Just imagine that you sprinkle this in hundreds of places in your codebase, and then an incompatible change is merged somewhere in the class chain. This could lead to massive amounts of technical debt and hours, days, or even weeks of wasted dev time.
• Testing Challenges: Since you don't always have direct access to all the classes behind the facade, you can not always do fine-grain testing of individual components.
• Data mutation issues: If the facade is used like a global Singelton where you're mutating some state from various other places, this could lead to dangerous inconsistencies in your data.