Skip to content

Design Pattern: Facade (Structural)

One simple door in front of a complex subsystem

Builds on Coupling and Cohesion

Stage 3core2 min read

The Complex Client Logic Problem

Here the client creates and coordinates five subsystems itself. The interface is "chatty": the client must make a fixed list of calls, in order, just to book one ticket.


1. Key Issues in this Design

Tight Coupling (System Fragility)

  • The Issue: The Main class is directly dependent on five separate concrete classes: PaymentService, SeatReservationService, NotificationService, LoyaltyPointsService, and TicketService.
  • The Impact: If any service changes a method signature (its name or inputs) or a constructor, the client breaks. The client "knows" too much about how the theater system works inside.

Violation of the "Law of Demeter"

  • The Issue: The Law of Demeter says to talk only to your close neighbors. Here the client talks to "strangers" (internal subsystems) it should not need to know.
  • The Impact: The client does not ask for a "Booking". It handles the payment, the seating and the ticket itself. So changes inside the subsystems reach the high-level code and break it.

Poor Reusability and Maintenance

  • The Issue: The booking steps sit in the Main method and would be copied elsewhere.
  • The Impact: To offer "Movie Booking" in a mobile app or a website, you would copy-paste this 10-line sequence. If the business rule changes (e.g., the ticket must be generated before points are added and the confirmation is sent, the reverse of this code), you must find and fix every copy.

High Cognitive Load

  • The Issue: A developer must learn the exact order of the calls to avoid bugs (e.g., accidentally generating a ticket before confirming payment).
  • The Impact: People make more mistakes, and new team members find the code harder to follow.

2. Structural Analysis

ComponentStatusObservation
Client (Main)OverburdenedCreates, coordinates and runs five subsystems.
SubsystemsExposedEvery internal service is visible to outside code, so there is more "surface area" (more places) for bugs.
WorkflowUnprotectedNo single "entry point" makes sure the booking steps are followed correctly.

3. Summary of the "Smell"

When a client needs to interact with a large number of diverse classes to perform a single task, the client is too complex. The Facade Pattern fixes this with a "Simplified Entry Point", a single class that makes these calls behind the scenes.

In this topic

Before code1 file

Before/Main.java68 linesGitHub
package DesignPatterns.StructuralPatterns.FacadeDesignPattern.Before;// Subsystem 1: Payment handlingclass PaymentService {    public void makePayment(String accountId, double amount) {        System.out.println("Payment of ₹" + amount + " successful for account " + accountId);    }}// Subsystem 2: Seat managementclass SeatReservationService {    public void reserveSeat(String movieId, String seatNumber) {        System.out.println("Seat " + seatNumber + " reserved for movie " + movieId);    }}// Subsystem 3: Communicationsclass NotificationService {    public void sendBookingConfirmation(String userEmail) {        System.out.println("Booking confirmation sent to " + userEmail);    }}// Subsystem 4: Rewards managementclass LoyaltyPointsService {    public void addPoints(String accountId, int points) {        System.out.println(points + " loyalty points added to account " + accountId);    }}// Subsystem 5: Ticket generationclass TicketService {    public void generateTicket(String movieId, String seatNumber) {        System.out.println("Ticket generated for movie " + movieId + ", Seat: " + seatNumber);    }}/** * PROBLEM: The Client (Main) is tightly coupled to FIVE different services. */class Main {    public static void main(String[] args) {        // ISSUE 1: Client "Over-knowledge"        // The client must know the exact order of operations and which service does what.                // ISSUE 2: Tight Coupling        // If the LoyaltyPointsService changes its method signature, this client code breaks.                // ISSUE 3: Lack of Reusability        // To book a ticket from a Mobile App or a Web Portal, you'd have to         // duplicate this 10-line sequence everywhere.        PaymentService paymentService = new PaymentService();        paymentService.makePayment("user123", 500);        SeatReservationService seatReservationService = new SeatReservationService();        seatReservationService.reserveSeat("movie456", "A10");        NotificationService notificationService = new NotificationService();        notificationService.sendBookingConfirmation("user@example.com");        LoyaltyPointsService loyaltyPointsService = new LoyaltyPointsService();        loyaltyPointsService.addPoints("user123", 50);        TicketService ticketService = new TicketService();        ticketService.generateTicket("movie456", "A10");    }}

Done with this topic?

How well do you know it?

PreviousDesign Pattern: Decorator (Structural)