Chapter 22: The Façade Pattern

In the previous chapter, we covered a third structural pattern, the bridge pattern, which helps to define an abstraction and its implementation in a decoupled way, so that both can vary independently. Now, we will learn about another structural pattern, the façade pattern, which achieves an important goal in many software use cases: hiding the inner workings of an application and only giving access to what is necessary.

In the chapter, we will discuss the following topics:

• Understanding the façade pattern
• Real-world examples
• Use cases
• Implementation

Throughout this chapter, we will see why façade is a good pattern to employ and what its benefits are, and as always, implement a hands-on example in Python.

Technical requirements

The code files for this chapter can be accessed through this link: https://github.com/PacktPublishing/Advanced-Python-Programming-Second-Edition/tree/main/Chapter22.

Understanding the façade pattern

As systems evolve, they can get very complex. It is not unusual to end up with a very large (and sometimes confusing) collection of classes and interactions. In many cases, we don't want to expose this complexity to the client. This is where façade comes to our rescue.

The façade design pattern helps us to hide the internal complexity of our systems and expose only what is necessary to the client through a simplified interface. In essence, a façade is an abstraction layer implemented over an existing complex system.

Let's take the example of a computer to illustrate things. A computer is a complex machine that depends on several parts to be fully functional. To keep things simple, the word computer, in this case, refers to an IBM derivative that uses a von Neumann architecture. Booting a computer is a particularly complex procedure. The CPU, main memory, and hard disk need to be up and running, the boot loader must...

Real-world examples

The façade pattern is quite common in life. When you call a bank or a company, you are usually first connected to the customer service department. The customer service employee acts as a façade between you and the actual department (billing, technical support, general assistance, and so on), and the employee that will help you with your specific problem.

Another example is the key used to turn on a car or motorcycle, which can also be considered a façade. It is a simple way of activating a system that is very complex internally. And, of course, the same is true for other complex electronic devices that we can activate with a single button, such as computers.

In software, the django-oscar-datacash module is a Django third-party module that integrates with the DataCash payment gateway. The module has a gateway class that provides fine-grained access to the various DataCash APIs. On top of that, it also offers a façade class that provides...

Use cases

The most common reason to use the façade pattern is to provide a single, simple entry point to a complex system. By introducing a façade, the client code can use a system by simply calling a single method/function. At the same time, the internal system does not lose any functionality; it just encapsulates it.

Not exposing the internal functionality of a system to the client code gives us an extra benefit: we can introduce changes to the system, but the client code remains unaware of and unaffected by the changes. No modifications are required to the client code.

The façade is also useful if you have more than one layer in your system. You can introduce one façade entry point per layer, and let all layers communicate with each other through their façades. This, in turn, promotes loose coupling and keeps the layers as independent as possible.

With that, we are now ready to try our hand at an actual implementation example in the next section...

Implementation

Assume that we want to create an OS using a multiserver approach, similar to how it is done in MINIX 3 (j.mp/minix3) or GNU Hurd (j.mp/gnuhurd). A multiserver OS has a minimal kernel, called the microkernel, which runs in privileged mode. All the other services of the system are following a server architecture (driver server, process server, file server, and so forth). Each server belongs to a different memory address space and runs on top of the microkernel in user mode. The pros of this approach are that the OS can become more fault-tolerant, reliable, and secure. For example, since all drivers are running in user mode on a driver server, a bug in a driver cannot crash the whole system, nor can it affect the other servers. The cons of this approach are the performance overhead and the complexity of system programming. These are a result of the communication happening between a server and the microkernel, as well as between the independent servers, using message passing...

Summary

In this chapter, we have learned how to use the façade pattern. This pattern is ideal for providing a simple interface to client code that wants to use a complex system but does not need to be aware of the system's complexity. We discussed a Django third-party module that uses façade: django-oscar-datacash. It uses the façade pattern to provide a simple DataCash API and the ability to save transactions.

We also learned how to implement the interface used by a multiserver OS. Overall, we learned that a façade is an elegant way of hiding the complexity of a system because, in most cases, the client code should not be aware of such details.

In the next chapter, we will cover other structural design patterns.

Questions

1. What are the high-level benefits of using the façade pattern?
2. How does using the façade pattern help when it comes to making changes to an application?
3. How is the façade pattern implemented in the Python example of the OS we considered?

Further reading

Design Patterns by Gamma Enrich, Helm Richard, Johnson Ralph, and Vlissides John available at https://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional-ebook/dp/B000SEIBB8