Design Patterns in Ruby – Structural Patterns – Facade Pattern

Intent (general)

Facade is a structural design pattern provides a simple interface for libraries, frameworks, or any other complex set of classes.

Problem

Imagine that you have to make your code work with a set of objects that belong to a library or framework. Normally, you need to initialize all those objects, track dependencies, execute methods in the correct order, etc.

Therefore, the business logic in your classes will become closely associated with the implementation details of 3rd party classes, making it difficult to understand and maintain.

Solution

The facade is a class that provides a simple interface for a complex subsystem that contains many moving parts. A facade can provide limited functionality compared to working directly with the subsystem. However, it only includes features that the customer really cares about.

The facade is handy when you need to integrate your application with a sophisticated library that has dozens of features, but you only need a bit of functionality.

For example, you have an application that helps upload funny short videos with cats to social media, using a professional video conversion library. However, all you really need is a single encode(filename, format) . After creating a class with such a method and connecting it to the video conversion library, you will have the first facade .

Real-World Analogy (contact with reality)

When you call a store to order by phone, an operator is your facade for all departmental services in the store. The operator provides you with a simple voice interface for ordering systems, payment gateways and various delivery services.

Structure (organization)

1. Facade provides convenient access to a specific part of the subsystem function. It knows where to perform client requests and how all components operate.
2. Additional Facade can be created to prevent pollution of a facade , extraneous features can make it another complex structure. Additional Facade can be used by both the Client and other facade .
3. Complex Subsystem includes dozens of different objects. To make all of them do something meaningful, you have to go into the subsystem implementation details, like initializing objects in the correct order and providing them data in the appropriate format. The subsystem class doesn't know about the existence of Facade . They operate in the system and work directly with each other.
4. Clients use Facade instead of calling subsystem objects directly.

Applicability (use when)

1. Use the Facade template when you need a limited but simple interface with complex subsystems.
2. Use Facade when you want to structure a subsystem into layers.

How to Implement (how to install)

1. Check to see if you can provide a simpler interface than what the existing subsystem has to offer. You can go in the right direction if this interface makes the client code independent of the sub-class of the subsystem.
2. Declare and implement this interface on the new facade class. Facade will redirect calls from the client code to the appropriate objects of the subsystem. Facade is responsible for initializing the subsystem and managing its next life cycle unless the client code has done this.
3. To get the full benefit of the pattern, make all client code communicate only with the subsystem via the facade. The client code is now separate from any changes in subsystem code. For example, when a subsystem is upgraded to the new version, you'll only need to modify the code on the facade.
4. If the facade becomes too large, consider extracting part of its behavior into a new facade class, be subtle.

Decorator in Ruby (example with ruby ​​language)

main.rb:

output.txt:

Refer

refactoring.guru