Facade Design Pattern (BPD)

In our goal to become professional developers, this article will explore the Facade Design Pattern introduced in the Design Patterns book.

Previously, I was preparing an article on the Single Responsibility Principle (SRP) from SOLID principles because I am currently reading Clean Architecture. At the beginning of that book, Uncle Bob explains the SOLID principles.

However, in a specific code example in the book, he presents a solution using the Facade Pattern. As a result, I decided to change the focus of our second article to this content.

GoF Design Patterns

The term GoF is: Gang of Four. Referring to the authors of Design Patterns: Elements of Reusable Object-Oriented.

The patterns in this book are divided into three categories:

Creational

Structural

Behavioral

[ ] – Singleton [ ] – Adapter [ ] – Template method
[ ] – Factory [ ] – Composite [ ] – Mediator
[ ] – Abstract Factory [ ] – Proxy [ ] – Chain of Responsibility
[ ] – Builder [ ] – Flyweight [ ] – Observer
[ ] – Prototype [x] – Facade [ ] – Strategy
[ ] – Bridge [ ] – Command
[ ] – Decorator [ ] – State
[ ] – Visitor
[ ] – Interpreter
[ ] – Iterator
[ ] – Memento

Maybe you’re thinking:

“I don’t need to know all these patterns.”

You’re right! You don’t need to know every patterns to earn money as a Developer. But our goal here is: Be a Professional Developer!

Undertanding these patterns can make it easier to grasp new frameworks, libs, etc. React, Angular, NodeJS, RxJS and others are inspired by these patterns 😊

 

Facade

What is it?

  • Structural design that provides a simplified interface to a complex subsystem.

Example

Imagine the platafform Booking.com. We can buy a complete trip using this single website.

  • Book a flight
  • Rent a car
  • Reserve a hotel…

It’s a complex environment because they likely have many integrations to offer this service.

And they have over 20.000 employees. Can you imagine that?

When dealing with large sofware systems like this, we create different squads to maintain and improve the system. We need to divide and conquer.

Code Example

  • Creating 3 different classes:
export class CarRental {
    rentCar() {
        console.log("Renting car...");
    }
}

export class FlightBooking {
    bookFlight() {
        console.log("Booking flight...");
    }
}

export class HotelReservation {
    bookRoom(): void {
        console.log("Booking room...")
    }
}
  • Creating Facade class:
import { CarRental } from "./car-rental";
import { FlightBooking } from "./flight-booking";
import { HotelReservation } from "./hotel-reservation";

export class TravelFacade {
    bookCompletePackage() {
        new FlightBooking().bookFlight();
        new HotelReservation().bookRoom();
        new CarRental().rentCar();
    }
}
  • Now we just create the index.ts:
import { TravelFacade } from "./travel/travel-facade";

new TravelFacade().bookCompletePackage()
  • And we received this return:
> node ./out/index.js

Booking flight...
Booking room...
Renting car...

We need to divide and conquer.

Advantages

  • Simplification of the interface
  • Reduced dependency
  • Encapsulation of the subsystem
  • Improved code readability
  • Easier maintenance and evolution

Conclusion

I enjoyed creating this example because I could see the benefits of using this design pattern. The more I study, the more I realize that any developer can make it work. However, only professionals can offer the best solutions for the future. 🙂

I aspire to be that professional. How about you?

Code

 

Previous Article

#1 – Be a professional DEVELOPER! (BPD)

 

Leave a Reply