Design Patterns in Python: Facade Pattern

The word “Façade” means the front of the building in French. Similarly, the Facade design pattern is an interface between the client and the system. It hides the complexity of the system, isolates it from the client. It provides a higher level interface so that a client doesn’t have to deal with all the subsystems of the system individually. So that the client can use the system more easily. The Facade system is one of the structural design patterns.

Implementation of Facade Design Pattern in Python

The word “Façade” means the front of the building in French. Similarly, the Facade design pattern is an interface between the client and the system. It hides the complexity of the system, isolates it from the client. It provides a higher level interface so that a client doesn’t have to deal with all the subsystems of the system individually. So that the client can use the system more easily. The Facade system is one of the structural design patterns.

Photo by Rishab Lamichhane on Unsplash

Photo by Rishab Lamichhane on Unsplash (source)

Systems are complex. For these systems to be usable, they must be simplified. Just as engineering creates complex systems, it must also simplify them. In our case, the dependency should be minimal between the client and the system. For example, a user should only press the button while turning on the computer and should not interfere with the rest. Those complex events that happen after the button is pressed are hidden from the user.

The solution to decrease the complexity within the systems themselves is to create subsystems. While the modular subsystems perform the tasks within their scope, they also become clients of each other and work together.

The facade design pattern maintains all the services provided by the subsystems to the client in a single facade interface.

Facade Pattern. Source

Facade Pattern. Source (source)

Thanks to this design pattern we can hide hidden or confidential processes from the client. We avoid duplication of work because not every client has to recreate the business logic. Complexity and fragility are reduced. We move the client away from domain information, system technology etc.

Implementation

Domain Problem

Let’s take a tire manufacturer as an example. A businessman builds a tire factory. As soon as he receives an order, he wants tires to be produced immediately. He doesn’t understand production or even the product itself, but he doesn’t want to understand either. This is not his job, it is the job of the hundreds of employees working in his factory and the subsystems there. He only cares whether the tires are built or not.

Tire Production Process. Source

Tire Production Process. Source (source)

Contrary to popular belief, car tires are quite complex products. Production processes are also complex. Since it is a composite product, a large number of parts are produced and assembled in different processes. As we see in the figure, subsystems are clients of each other. The real client is the boss. The boss (client) asks the plant (system) to produce tires, and plant accomplish this request with the help of its subsystems.

Coding

                class RawMaterials:
    
    def get_materials(self):
        return "Materials arrived."
    
class Mixing:
    
    def mix_materials(self):
        return "Mixing done."
    
class Calenders:
    
    def cut_cords(self):
        return "Cord materials are cut."

class Building:
    
    def assembly_tires(self):
        return "Green tire is obtained."
    
class Curing: 
    
    def cure_tires(self):
        return "Tires are cured."
    
class FinalFinish:
    
    def test_tires(self):
        return "Tires are tested."
    
class Logistics:
    
    def send_tires(self):
        return "Tires are sold. You can buy a new Maserati"

    
class FacadeTire:
    
    def __init__(self):
        self.raw = RawMaterials()
        self.mixer = Mixing()
        self.calender = Calenders()
        self.builder = Building()
        self.cure = Curing()
        self.tester = FinalFinish()
        self.trucks = Logistics()
        
    def sell_tires(self):
        result = self.raw.get_materials()
        result += " " + self.mixer.mix_materials()
        result += " " + self.calender.cut_cords()
        result += " " + self.builder.assembly_tires()
        result += " " + self.cure.cure_tires()
        result += " " + self.tester.test_tires()
        result += " " + self.trucks.send_tires()
        return result
            

Each subsystem in tire production has its own class and methods defined. If the client did not have facade, it would have to establish a one-to-one relationship with these processes every time and would have to know about the changes to be made to these systems.

Facade class.

Facade class.

With the facade class, we standardized this whole process and hidden it from the client. The client can only invoke this class and make the necessary operations performed.

                FACADE = FacadeTire()
result = FACADE.sell_tires()
#OUT:
'Materials arrived. Mixing done. Cord materials are cut. Green tire is obtained. Tires are cured. Tires are tested. Tires are sold. You can buy a new Maserati'
            

Facade is a nice way to provide simple solutions to clients in case of complex systems. It combines lots of subsystems that the client doesn’t want to use directly.

Next Episode

Design Patterns in Python: Proxy Pattern

Read More…

Design Patterns in Python: Builder Pattern

References

https://en.wikipedia.org/wiki/Facade_pattern

https://refactoring.guru/design-patterns/facade

Design Patterns - Facade Pattern


Only registered users can post comments. Please, login or signup.

Start blogging about your favorite technologies and get more readers

Join other developers and claim your FAUN account now!

Stats
18

Influence

590

Total Hits

3

Posts