Facade Design Pattern in Software Development

The Facade Design Pattern is a structural Design Pattern.

Purpose:
The Facade design pattern provides a unified interface to a set of interfaces in a subsystem. This pattern defines a higher-level interface that makes the subsystem easier to use.

Explanation:
You have created a Line Of Business(LOB) Application. This application consists of various modules or subsystems with different functionalities.
If you are the end-user of this LOB application then to achieve a particular business goal, you will perform actions on the different screens in a particular order following certain business rules.

If this or a part of this business process could be automated without human interaction through an API call by a client application then this client application would need to know the business rules or logic and call the different modules/subsystems methods accordingly.

This has the following disadvantages:

1. Client has now a dependency on the various module/subsystem methods.
2. If there are changes to the module/subsystem methods, the client might have to make changes to its call.
3. If business rules change, then the client will have to make changes at its end to cater to the business rules change — this is totally unacceptable as the client is not supposed to be involved in any business rules.
4. How will the client take care of any/multiple failure scenarios?

The solution to this issue is that you expose to the client different Facade class methods each serving a different business goal.

In this case the client will call the Facade class method/s and not worry about dependencies to various modules/sub systems, business rule changes and any failure scenarios.

As the client is now exposed only to the Facade interface/s the number of failure points has dramatically decreased for the client and also there will be no changes that need to be done on the client side.

Facade class and its methods creation is particularly useful for bigger complex modules/subsystems with frameworks and libraries references else the Facade interface will become an unwanted overhead layer.

One important care that needs to be taken is that the Facade class should not become an unwanted “God Object” (an object that knows too much or does too much), else it will lead to tight coupling and challenges in code maintainability.

UML Diagram:

Participants

1. Facade Class :
   It knows which subsystem classes are responsible for a request.
   It delegates client requests to appropriate subsystem objects.
2. Subsystem Classes:
   They implement subsystem functionality.
   They handle work assigned by the Facade object.
   They have no knowledge of the facade and keep no reference to it.

Real-world code in C#:

Points:

1. Facade is a structural design pattern with the intent to provide a simplified (but limited) interface to a complex system of classes, library or framework.
2. A Facade class can often be transformed into a Singleton since a single facade object is sufficient in most cases.
3. Facade routinely wraps multiple objects.
4. The Facade class will not encapsulate subclasses but will provide a simple interface to their functions.
5. Classes in the subsystem will still be available to the client. However, Facade will decouple client and subsystems so that they can change independently.
6. We can combine different features by writing different Facade classes for different clients.
7. Facade can be recognized in a class that has a simple interface, but delegates most of the work to other classes.
8. Usually, facades manage the full life cycle of objects they use.
9. Client is shielded from the unwanted complexities of the subsystems and gets only to a fraction of a subsystem’s capabilities.
10. Abstract Factory can serve as an alternative to Facade when you only want to hide the way the subsystem objects are created from the client code.

Usage:

1. Use the Facade pattern when you need to have a limited but straightforward interface to a complex subsystem.
2. Use the Facade when you want to structure a subsystem into layers.

Related Patterns:

1. Combined with Abstract Factory or used as an alternative to it.
2. Often confused with Adapter and mediator patterns.

Some use cases in Enterprise Applications:

1. Decoupling Application Code From the Library.
2. Reusing Legacy Code in New Application.
3. Fixing Interface Segregation Principle Violation.

Facade Pattern in the .NET Framework

MessageBox (System.Windows.Forms) — provides a reusable high level interface to some of the Windows Forms interfaces, instead of writing a whole lot of code to present a dialog you can just call MessageBox.Show(“Hello world”);

This is also mentioned in Design Patterns in C# by Steven John Metsker:

“The MessageBox class is one of the few examples of a facade in the FCL. It is production-worthy, configurable, and designed for reuse. Above all else, the MessageBox class fulfills the intent of the FACADE pattern by providing a simple interface that makes it easy to display dialogs.”

Usage in Strangler Pattern in Application Migration/Modernization:

Strangler Pattern is a way of migrating a legacy system incrementally by replacing existing functionalities with modern applications and services in a phased approach. After the replacement of the entire functionality the modern application system eventually replaces all the old legacy system’s features.
A strangler Façade layer will act as an interface to route requests between legacy and modern applications and services.
Strangler Fig Pattern is used as a cloud design pattern.
The strangler pattern is also used in migrating a Monolithic application to Microservice Architecture by gradually replacing specific functionality with new Microservices. Also, new functionalities are only added in Microservices, bypassing the legacy Monolithic application.
A Façade (API Gateway) is then configured to route the requests between the legacy Monolith and Microservices. Once the functionality is migrated from the Monolith to Microservices, the Facade then intercepts the client request and route to the new Microservices. Once all the legacy monolith’s functionalities are migrated, the legacy Monolithic application is “strangled,” i.e., decommissioned.

References:

C# Facade

Facade

Design Patterns and Refactoring

Facade | Cheat Sheet

3 Main Use Cases of the Facade Design Pattern in Enterprise Applications

What design patterns are used throughout the .NET Framework?

Microservice Architecture and its 10 Most Important Design Patterns

Strangler Fig pattern - Cloud Design Patterns