Structural Design Patterns

Structural design patterns are concerned with the composition of classes and objects. They focus on how to assemble classes and objects into larger structures while keeping these structures flexible and efficient. Adapter Pattern is one of the most important structural design patterns. Let's understand in depth.

Adapter Pattern

The Adapter Pattern allows incompatible interfaces to work together by acting as a translator or wrapper around an existing class. It converts the interface of a class into another interface that a client expects.

It acts as a bridge between the Target interface (expected by the client) and the Adaptee (an existing class with a different interface). This structural wrapping enables integration and compatibility across diverse systems.

Real-Life Analogy

Problem It Solves

• Interface incompatibility between classes.
• Reusability of existing classes without modifying their source code.
• Enables systems to communicate that otherwise couldn't due to differing method signatures.

Similarly, the Adapter Pattern allows objects with incompatible interfaces to collaborate by introducing an adapter.

Real-Life Coding Example

Let's consider a scenario where we are implementing the Payment Gateway System. And we have two different payment methods: PayU and Razorpay. While the PayU gateway already conforms to this interface, Razorpay follows a different structure as shown in the code below.

Using Incompatible Interface (Without Adapter)

// ⚠️ ANTI-PATTERN — this is the version we are about to fix. Do not copy it.
import java.util.*;
 
// Target Interface:
// Standard interface expected by the CheckoutService
interface PaymentGateway {
    void pay(String orderId, double amount);
}
 
// Concrete implementation of PaymentGateway for PayU
class PayUGateway implements PaymentGateway {
    @Override
    public void pay(String orderId, double amount) {
        System.out.println("Paid Rs. " + amount + " using PayU for order: " + orderId);
    }
}
 
// Adaptee:
// An existing class with an incompatible interface
class RazorpayAPI {
    public void makePayment(String invoiceId, double amountInRupees) {
        System.out.println("Paid Rs. " + amountInRupees + " using Razorpay for invoice: " + invoiceId);
    }
}
 
// Client Class:
// Uses PaymentGateway interface to process payments
class CheckoutService {
    private PaymentGateway paymentGateway;
 
    // Constructor injection for dependency inversion
    public CheckoutService(PaymentGateway paymentGateway) {
        this.paymentGateway = paymentGateway;
    }
 
    // Business logic to perform checkout
    public void checkout(String orderId, double amount) {
        paymentGateway.pay(orderId, amount);
    }
}
 
// ── Driver ──────────────────────────────────────────────
class Main {
    public static void main(String[] args) {
        // Using PayU payment gateway to process payment
        CheckoutService checkoutService = new CheckoutService(new PayUGateway());
        checkoutService.checkout("12", 1780);
 
        // RazorpayAPI cannot be passed to CheckoutService at all — it does not
        // implement PaymentGateway, so `new CheckoutService(new RazorpayAPI())`
        // is a compile error. The only way to use it is to bypass
        // CheckoutService entirely and call its own method directly.
        System.out.println();
        System.out.println("Falling back to RazorpayAPI directly, bypassing CheckoutService:");
        RazorpayAPI razorpayAPI = new RazorpayAPI();
        razorpayAPI.makePayment("13", 1780);
 
        System.out.println();
        System.out.println("ANTI-PATTERN: RazorpayAPI cannot be used through CheckoutService - interface incompatibility.");
    }
}

Understanding the Issues

• CheckoutService expects any payment provider to implement the PaymentGateway interface.
• PayUGateway fits this requirement and works correctly.
• RazorpayAPI, however, uses a different method (makePayment) and does not implement PaymentGateway.
• Due to this mismatch, RazorpayAPI cannot be used directly with CheckoutService.

This is a case of interface incompatibility, where similar functionalities can't work together because of structural differences. To solve this without modifying existing code, we use the Adapter Pattern to make RazorpayAPI compatible with the expected interface.

Using Adapter Pattern

import java.util.*;
 
// Target Interface:
// Standard interface expected by the CheckoutService
interface PaymentGateway {
    void pay(String orderId, double amount);
}
 
// Concrete implementation of PaymentGateway for PayU
class PayUGateway implements PaymentGateway {
    @Override
    public void pay(String orderId, double amount) {
        System.out.println("Paid Rs. " + amount + " using PayU for order: " + orderId);
    }
}
 
// Adaptee:
// An existing class with an incompatible interface
class RazorpayAPI {
    public void makePayment(String invoiceId, double amountInRupees) {
        System.out.println("Paid Rs. " + amountInRupees + " using Razorpay for invoice: " + invoiceId);
    }
}
 
// Adapter Class:
// Allows RazorpayAPI to be used where PaymentGateway is expected
class RazorpayAdapter implements PaymentGateway {
    private RazorpayAPI razorpayAPI;
 
    public RazorpayAdapter() {
        this.razorpayAPI = new RazorpayAPI();
    }
 
    // Translates the pay() call to RazorpayAPI's makePayment() method
    @Override
    public void pay(String orderId, double amount) {
        razorpayAPI.makePayment(orderId, amount);
    }
}
 
// Client Class:
// Uses PaymentGateway interface to process payments
class CheckoutService {
    private PaymentGateway paymentGateway;
 
    // Constructor injection for dependency inversion
    public CheckoutService(PaymentGateway paymentGateway) {
        this.paymentGateway = paymentGateway;
    }
 
    // Business logic to perform checkout
    public void checkout(String orderId, double amount) {
        paymentGateway.pay(orderId, amount);
    }
}
 
// ── Driver ──────────────────────────────────────────────
class Main {
    public static void main(String[] args) {
        // Using PayU payment gateway to process payment
        CheckoutService payuCheckout = new CheckoutService(new PayUGateway());
        payuCheckout.checkout("12", 1780);
 
        System.out.println();
 
        // Using the Razorpay adapter to process payment through the same
        // CheckoutService - no incompatibility this time.
        CheckoutService razorpayCheckout = new CheckoutService(new RazorpayAdapter());
        razorpayCheckout.checkout("13", 1780);
 
        System.out.println();
        System.out.println("GOOD DESIGN: RazorpayAdapter lets RazorpayAPI flow through CheckoutService like any other gateway.");
    }
}

The same idea in Python

from abc import ABC, abstractmethod
 
 
class PaymentGateway(ABC):
    # Target interface. Duck typing means Python doesn't strictly need this --
    # any object with a matching pay() method would work -- but abc.ABC makes
    # the contract explicit and fails fast (TypeError) if a subclass forgets pay().
    @abstractmethod
    def pay(self, order_id: str, amount: float) -> None:
        ...
 
 
class PayUGateway(PaymentGateway):
    def pay(self, order_id: str, amount: float) -> None:
        print(f"Paid Rs. {amount} using PayU for order: {order_id}")
 
 
class RazorpayAPI:
    """Adaptee: an existing class with an incompatible interface."""
 
    def make_payment(self, invoice_id: str, amount_in_rupees: float) -> None:
        print(f"Paid Rs. {amount_in_rupees} using Razorpay for invoice: {invoice_id}")
 
 
class RazorpayAdapter(PaymentGateway):
    """Adapter: translates pay() calls to RazorpayAPI's make_payment()."""
 
    def __init__(self) -> None:
        self._razorpay_api = RazorpayAPI()
 
    def pay(self, order_id: str, amount: float) -> None:
        self._razorpay_api.make_payment(order_id, amount)
 
 
class CheckoutService:
    def __init__(self, payment_gateway: PaymentGateway) -> None:
        self._payment_gateway = payment_gateway
 
    def checkout(self, order_id: str, amount: float) -> None:
        self._payment_gateway.pay(order_id, amount)
 
 
# ── Driver ──────────────────────────────────────────────
if __name__ == "__main__":
    payu_checkout = CheckoutService(PayUGateway())
    payu_checkout.checkout("12", 1780)
 
    print()
 
    razorpay_checkout = CheckoutService(RazorpayAdapter())
    razorpay_checkout.checkout("13", 1780)
 
    print()
    print("GOOD DESIGN: RazorpayAdapter lets RazorpayAPI flow through CheckoutService like any other gateway.")

Note: unlike Java, Python doesn't require RazorpayAdapter to declare implements PaymentGateway for duck typing to work — any object with a matching pay() method would satisfy CheckoutService. The abc.ABC base is used anyway so the contract is explicit and a missing method fails fast at instantiation, rather than at the first call.

Here, we created an adapter class RazorpayAdapter that implements the PaymentGateway interface. The adapter internally uses the RazorpayAPI class and translates the method calls from the expected interface to the actual implementation.

This allows us to use RazorpayAPI seamlessly with the CheckoutService without modifying either class.

When to Use Adapter Pattern

The Adapter Pattern is ideal in scenarios where you're trying to integrate components that were not originally designed to work together. It proves especially useful when:

• You need to use an existing class, but its interface does not match the one your system expects.
• You want to reuse legacy code without modifying its internal structure.
• You're integrating third-party APIs or external services into your application.

In such cases, the Adapter Pattern serves as a bridge, allowing seamless compatibility without altering existing codebases.

Advantages and Disadvantages

Like any design pattern, the Adapter Pattern comes with its own set of pros and cons:

Pros

• Code Reusability: Encourages the reuse of existing classes without changing their implementation.
• Code Extensibility: Makes systems more flexible and adaptable to change.
• Minimal Changes to Client Code: Enables integration without requiring modifications to existing client logic.
• Simplifies Third-party Integration: Makes it easier to incorporate external services and APIs.

Cons

• Adds an Extra Layer of Abstraction: Can introduce unnecessary complexity if not used judiciously.
• Overuse Can Obscure System Design: Excessive use of adapters might make the architecture harder to understand and maintain.

Real Product Use Cases

The Adapter Pattern is not just a theoretical concept - it plays a crucial role in real-world software products and systems. Many enterprise-level applications rely on this pattern to integrate with third-party tools, legacy systems, and platform-specific APIs. Below are some common and impactful use cases:

1. Payment Gateways — Different payment providers (e.g., PayPal, Stripe, Razorpay, PayU) expose their own APIs with varying method names, parameters, and response formats. By implementing a common PaymentGateway interface and creating adapters for each provider, businesses can switch or support multiple gateways without rewriting business logic. This decouples the checkout flow from provider-specific implementations.
2. Logging Frameworks — Enterprise applications often need to support different logging libraries like Log4j, SLF4J, or custom logging solutions. An adapter can unify the logging interface so developers can write log.debug(...), regardless of whether the underlying implementation is Log4j or java.util.logging. This makes it easier to switch or support multiple logging backends with minimal changes.
3. Cloud Providers and SDKs — Cloud platforms like AWS, Azure, and Google Cloud offer similar functionalities (storage, compute, database) but expose them through different SDKs and APIs. Using an adapter layer, developers can abstract cloud operations behind a common interface, enabling them to change providers (e.g., from AWS S3 to Google Cloud Storage) without impacting the rest of the application. This is particularly useful for hybrid-cloud or multi-cloud strategies.

Class Diagram

The class diagram below illustrates the Adapter Pattern. The PaymentGateway interface is the target interface, while RazorpayAPI is the adaptee. The RazorpayAdapter acts as a bridge, allowing the client to interact with the adaptee through the target interface.

Decorator Pattern

The Decorator Pattern is a structural design pattern that allows behavior to be added to individual objects, dynamically at runtime, without affecting the behavior of other objects from the same class.

It wraps an object inside another object that adds new behaviors or responsibilities at runtime, keeping the original object's interface intact.

Real-Life Analogy

Problem It Solves

It solves the problem of class explosion that occurs when you try to use inheritance to add combinations of behavior. For example, imagine you have:

• A Pizza
• A CheesePizza
• A CheeseAndOlivePizza
• A CheeseAndOliveStuffedPizza

Every combination would need a new subclass as shown in the code below.

// ⚠️ ANTI-PATTERN — this is the version we are about to fix. Do not copy it.
import java.util.*;
 
// Each combination of pizza requires a new class
class PlainPizza {}
class CheesePizza extends PlainPizza {}
class OlivePizza extends PlainPizza {}
class StuffedPizza extends PlainPizza {}
class CheeseStuffedPizza extends CheesePizza {}
class CheeseOlivePizza extends CheesePizza {}
class CheeseOliveStuffedPizza extends CheeseOlivePizza {}
 
// ── Driver ──────────────────────────────────────────────
class Main {
    public static void main(String[] args) {
        // Base pizza
        PlainPizza plainPizza = new PlainPizza();
        System.out.println("Created: " + plainPizza.getClass().getSimpleName());
 
        // Pizzas with individual toppings
        CheesePizza cheesePizza = new CheesePizza();
        System.out.println("Created: " + cheesePizza.getClass().getSimpleName());
        OlivePizza olivePizza = new OlivePizza();
        System.out.println("Created: " + olivePizza.getClass().getSimpleName());
        StuffedPizza stuffedPizza = new StuffedPizza();
        System.out.println("Created: " + stuffedPizza.getClass().getSimpleName());
 
        // Combinations of toppings require separate classes
        CheeseStuffedPizza cheeseStuffedPizza = new CheeseStuffedPizza();
        System.out.println("Created: " + cheeseStuffedPizza.getClass().getSimpleName());
        CheeseOlivePizza cheeseOlivePizza = new CheeseOlivePizza();
        System.out.println("Created: " + cheeseOlivePizza.getClass().getSimpleName());
 
        // Further combinations increase complexity exponentially
        CheeseOliveStuffedPizza cheeseOliveStuffedPizza = new CheeseOliveStuffedPizza();
        System.out.println("Created: " + cheeseOliveStuffedPizza.getClass().getSimpleName());
 
        System.out.println();
        System.out.println("ANTI-PATTERN: 7 classes for 4 toppings, and every new combination needs one more.");
    }
}

This quickly becomes unmanageable. Here, the Decorator Pattern comes into play. It lets you compose behaviors using wrappers instead of subclassing.

Solution to Pizza Problem

The Decorator Pattern solves the above discussed Pizza problem. It allows us to add responsibilities (like toppings) to objects dynamically without modifying their structure.

Instead of relying on a rigid class hierarchy, we compose objects using wrappers. This promotes flexibility, scalability, and cleaner code architecture.

Using Decorator Pattern

import java.util.*;
 
// =========== Component Interface ============
interface Pizza {
    String getDescription();
    double getCost();
}
 
// ============= Concrete Components: Base pizza ==============
class PlainPizza implements Pizza {
    @Override
    public String getDescription() {
        return "Plain Pizza";
    }
 
    @Override
    public double getCost() {
        return 150.00;
    }
}
 
class MargheritaPizza implements Pizza {
    @Override
    public String getDescription() {
        return "Margherita Pizza";
    }
 
    @Override
    public double getCost() {
        return 200.00;
    }
}
 
// ======================== Abstract Decorator ===========================
// ====== Implements Pizza and holds a reference to a Pizza object =======
abstract class PizzaDecorator implements Pizza {
    protected Pizza pizza;
 
    public PizzaDecorator(Pizza pizza) {
        this.pizza = pizza;
    }
}
 
// ============ Concrete Decorator: Adds Extra Cheese ================
class ExtraCheese extends PizzaDecorator {
    public ExtraCheese(Pizza pizza) {
        super(pizza);
    }
 
    @Override
    public String getDescription() {
        return pizza.getDescription() + ", Extra Cheese";
    }
 
    @Override
    public double getCost() {
        return pizza.getCost() + 40.0;
    }
}
 
// ============ Concrete Decorator: Adds Olives ================
class Olives extends PizzaDecorator {
    public Olives(Pizza pizza) {
        super(pizza);
    }
 
    @Override
    public String getDescription() {
        return pizza.getDescription() + ", Olives";
    }
 
    @Override
    public double getCost() {
        return pizza.getCost() + 30.0;
    }
}
 
// =========== Concrete Decorator: Adds Stuffed Crust Cheese ==============
class StuffedCrust extends PizzaDecorator {
    public StuffedCrust(Pizza pizza) {
        super(pizza);
    }
 
    @Override
    public String getDescription() {
        return pizza.getDescription() + ", Stuffed Crust";
    }
 
    @Override
    public double getCost() {
        return pizza.getCost() + 50.0;
    }
}
 
// ── Driver ──────────────────────────────────────────────
class Main {
    public static void main(String[] args) {
        // Start with a basic Margherita Pizza
        Pizza myPizza = new MargheritaPizza();
 
        // Add Extra Cheese
        myPizza = new ExtraCheese(myPizza);
 
        // Add Olives
        myPizza = new Olives(myPizza);
 
        // Add Stuffed Crust
        myPizza = new StuffedCrust(myPizza);
 
        // Final Description and Cost
        System.out.println("Pizza Description: " + myPizza.getDescription());
        System.out.println("Total Cost: ₹" + myPizza.getCost());
 
        System.out.println();
        System.out.println("GOOD DESIGN: one class per topping, composed at runtime instead of multiplying subclasses.");
    }
}

The same idea in Python

from abc import ABC, abstractmethod
 
 
class Pizza(ABC):
    @abstractmethod
    def get_description(self) -> str:
        ...
 
    @abstractmethod
    def get_cost(self) -> float:
        ...
 
 
class PlainPizza(Pizza):
    def get_description(self) -> str:
        return "Plain Pizza"
 
    def get_cost(self) -> float:
        return 150.00
 
 
class MargheritaPizza(Pizza):
    def get_description(self) -> str:
        return "Margherita Pizza"
 
    def get_cost(self) -> float:
        return 200.00
 
 
class PizzaDecorator(Pizza, ABC):
    # Abstract decorator: implements Pizza and holds a reference to a Pizza --
    # this is the GoF object-wrapping Decorator. Python also has function
    # decorators (@syntax), a different mechanism for wrapping callables, not
    # objects; don't conflate the two -- this block is the GoF pattern only.
    def __init__(self, pizza: Pizza) -> None:
        self._pizza = pizza
 
 
class ExtraCheese(PizzaDecorator):
    def get_description(self) -> str:
        return self._pizza.get_description() + ", Extra Cheese"
 
    def get_cost(self) -> float:
        return self._pizza.get_cost() + 40.0
 
 
class Olives(PizzaDecorator):
    def get_description(self) -> str:
        return self._pizza.get_description() + ", Olives"
 
    def get_cost(self) -> float:
        return self._pizza.get_cost() + 30.0
 
 
class StuffedCrust(PizzaDecorator):
    def get_description(self) -> str:
        return self._pizza.get_description() + ", Stuffed Crust"
 
    def get_cost(self) -> float:
        return self._pizza.get_cost() + 50.0
 
 
# ── Driver ──────────────────────────────────────────────
if __name__ == "__main__":
    my_pizza: Pizza = MargheritaPizza()
    my_pizza = ExtraCheese(my_pizza)
    my_pizza = Olives(my_pizza)
    my_pizza = StuffedCrust(my_pizza)
 
    print(f"Pizza Description: {my_pizza.get_description()}")
    print(f"Total Cost: ₹{my_pizza.get_cost()}")
 
    print()
    print("GOOD DESIGN: one class per topping, composed at runtime instead of multiplying subclasses.")

Note: Python also has function decorators (the @decorator syntax used on functions and methods elsewhere in this book) — that is a different mechanism, for wrapping a callable, not an object. The GoF Decorator Pattern shown here is about wrapping objects that share an interface; the two ideas are related in spirit but not the same tool.

Understanding the Code

The above code:

• Defines a Pizza interface that all pizzas (base and decorated) must implement.
• Implements two concrete PlainPizza and MargheritaPizza as the base pizzas.
• Defines an abstract PizzaDecorator which wraps a Pizza object and forwards method calls to it.
• Implements concrete decorators like ExtraCheese, Olives, and StuffedCrust which extend the functionality of the pizza object.

In the main method:

• A plain Margherita pizza is created.
• It is then wrapped successively with different decorators: ExtraCheese, Olives, and StuffedCrust.
• Each decorator adds to the pizza's description and cost.
• Finally, the composed pizza's description and total cost are printed.

How Decorator Pattern Solves the Issue

• Avoids Class Explosion: You no longer need a separate class for each combination of toppings. Just create new decorators as needed.
• Flexible & Scalable: Toppings can be added, removed, or reordered at runtime, offering high customization.
• Follows Open/Closed Principle: The base Pizza classes are open for extension (via decorators) but closed for modification.
• Cleaner Code Architecture: Composition is used instead of inheritance, resulting in loosely coupled components.
• Promotes Reusability: Each topping is a self-contained decorator and can be reused across different pizza compositions.

Key Takeaways

• Abstract Classes and Constructors: Abstract classes can have constructors, and these constructors are executed when a subclass is instantiated. This is important for initializing common properties or behavior shared across all subclasses.
• Decorator as Layers: Each decorator acts like a layer, similar to wrapping a gift box. Every decorator adds behavior on top of the previous one, allowing for flexible and dynamic composition of functionality.
• Call Stack Analogy: The Decorator Pattern functions like a call stack, where behavior is accumulated step by step as each decorator wraps the component. This stacked behavior is then unwrapped during method calls, preserving the order and layering.
• Loose Coupling Between Classes: The use of interfaces and composition in the Decorator Pattern ensures loose coupling between components. This makes the system more flexible, testable, and easier to extend without affecting existing code.

When Should You Use the Decorator Pattern?

The Decorator Pattern is particularly useful in scenarios where flexibility, modularity, and extensibility are key. Consider using it when:

• You need to add responsibilities to objects dynamically: Instead of hardcoding behaviors into a class, decorators allow you to attach additional functionality at runtime, offering great flexibility.
• You want to avoid an explosion of subclasses: For every possible combination of features, creating separate subclasses leads to unmanageable and bloated class hierarchies. Decorators eliminate this by composing behaviors.
• You want to follow the Open/Closed Principle (OCP): The pattern supports the OCP by allowing classes to be open for extension but closed for modification. You enhance behavior without altering existing code.
• You want reusable and composable behaviors: Decorators can be reused across different components and can be composed in various combinations to achieve desired functionality.
• You need layered, step-by-step enhancements: Decorators can be applied one after another, layering features gradually in a controlled and traceable way — much like wrapping layers around an object.

Advantages

A few advantages of using the Decorator Pattern are:

• Adheres to the Open/Closed Principle (OCP): Enhancements can be made without modifying existing code, supporting scalability and maintainability.
• Runtime Flexibility to Compose Features: Behaviors can be added or removed dynamically, allowing for highly customizable solutions.
• Avoids Subclass Explosion: Instead of creating multiple subclasses for every feature combination, decorators provide a cleaner, more modular approach.
• Promotes Single Responsibility for Each Add-on: Each decorator focuses on a specific functionality, leading to better code organization and readability.

Disadvantages

A few trade-offs while using the Decorator Pattern are:

• Can Result in Many Small Classes: Each feature typically requires its own decorator class, which can clutter the codebase.
• Stack Trace Debugging is Difficult: Debugging layered decorators can be challenging, as stack traces may become complex and harder to trace.
• Overhead of Multiple Wrapping Classes: Composing many decorators can introduce runtime overhead and make the class structure harder to follow.
• Developers Must Understand Decorator Flow: Proper implementation requires developers to grasp the decorator chaining logic, which may introduce a learning curve.

Real-World Use Cases

The Decorator Pattern is widely used in real-life software products to enable dynamic behavior composition without bloating the class hierarchy. Below are practical examples where it plays a critical role:

1. Food Delivery Applications (e.g., Swiggy, Zomato) — Customers can customize food items with add-ons like extra cheese, sauces, toppings, or side dishes. Each add-on modifies the base food item's description and price dynamically. Instead of creating subclasses for every combination (e.g., PizzaWithCheeseAndOlives), decorators like CheeseDecorator, OliveDecorator, etc., can be stacked over a base Pizza. This allows the system to stay open for extension (new add-ons) but closed for modification.
2. Google Docs or Word Processors — Users can apply text formatting like bold, italic, or underline independently or in combination. Each text style is implemented as a decorator that wraps the plain text object, allowing flexible layering of styles, e.g., UnderlineDecorator(BoldDecorator(ItalicDecorator(Text))). This avoids subclassing for all combinations like BoldItalicUnderlineText, keeping the design clean and extensible.

Class Diagram

The class diagram for the Decorator Pattern illustrates the relationship between the component interface, concrete components, and decorators. It shows how decorators extend the functionality of components without modifying their structure.

Facade Pattern

The Facade Pattern is a structural design pattern that provides a simplified, unified interface to a complex subsystem or group of classes.

It acts as a single entry point for clients to interact with the system, hiding the underlying complexity and making the system easier to use.

Real-Life Analogy

In short, the manual car exposes the complexity, while the automatic car (the facade) simplifies it for the user.

Problem It Solves

It solves the problem of dealing with complex subsystems by hiding the complexities behind a single, unified interface. For example, imagine a movie ticket booking system with:

• PaymentService
• SeatReservationService
• NotificationService
• LoyaltyPointsService
• TicketService

Instead of making the client interact with all of these directly, the Facade Pattern provides a single class like MovieBookingFacade, which internally coordinates all the services.

Real-Life Coding Example

Imagine you're developing a movie ticket booking application, like BookMyShow. Let's first take a look at a poorly structured approach to implementing the booking functionality.

The Bad Way (Without Using Facade Pattern)

// ⚠️ ANTI-PATTERN — this is the version we are about to fix. Do not copy it.
 
// Service class responsible for handling payments
class PaymentService {
    public void makePayment(String accountId, double amount) {
        System.out.println("Payment of ₹" + amount + " successful for account " + accountId);
    }
}
 
// Service class responsible for reserving seats
class SeatReservationService {
    public void reserveSeat(String movieId, String seatNumber) {
        System.out.println("Seat " + seatNumber + " reserved for movie " + movieId);
    }
}
 
// Service class responsible for sending notifications
class NotificationService {
    public void sendBookingConfirmation(String userEmail) {
        System.out.println("Booking confirmation sent to " + userEmail);
    }
}
 
// Service class for managing loyalty/reward points
class LoyaltyPointsService {
    public void addPoints(String accountId, int points) {
        System.out.println(points + " loyalty points added to account " + accountId);
    }
}
 
// Service class for generating movie tickets
class TicketService {
    public void generateTicket(String movieId, String seatNumber) {
        System.out.println("Ticket generated for movie " + movieId + ", Seat: " + seatNumber);
    }
}
 
// ── Driver ──────────────────────────────────────────────
class Main {
    public static void main(String[] args) {
        // Booking a movie ticket manually (without a facade)
 
        // Step 1: Make payment
        PaymentService paymentService = new PaymentService();
        paymentService.makePayment("user123", 500);
 
        // Step 2: Reserve seat
        SeatReservationService seatReservationService = new SeatReservationService();
        seatReservationService.reserveSeat("movie456", "A10");
 
        // Step 3: Send booking confirmation via email
        NotificationService notificationService = new NotificationService();
        notificationService.sendBookingConfirmation("[email protected]");
 
        // Step 4: Add loyalty points to user's account
        LoyaltyPointsService loyaltyPointsService = new LoyaltyPointsService();
        loyaltyPointsService.addPoints("user123", 50);
 
        // Step 5: Generate the ticket
        TicketService ticketService = new TicketService();
        ticketService.generateTicket("movie456", "A10");
 
        System.out.println();
        System.out.println("ANTI-PATTERN: the client orchestrates all five services itself, in the right order, every time.");
    }
}

While this code works, it's tightly coupled. The Main class (or client code) is manually calling each subsystem service in the correct order and with the correct parameters.

This leads to:

• High complexity for the client
• Duplicate code if you have to do this in multiple places
• Violation of the Single Responsibility Principle (the Main class knows too much)

This sets the stage for the Facade Pattern, which will encapsulate all these steps in one high-level method like bookTicket() and make the client code clean and readable.

Using Facade Pattern

// Service class responsible for handling payments
class PaymentService {
    public void makePayment(String accountId, double amount) {
        System.out.println("Payment of ₹" + amount + " successful for account " + accountId);
    }
}
 
// Service class responsible for reserving seats
class SeatReservationService {
    public void reserveSeat(String movieId, String seatNumber) {
        System.out.println("Seat " + seatNumber + " reserved for movie " + movieId);
    }
}
 
// Service class responsible for sending notifications
class NotificationService {
    public void sendBookingConfirmation(String userEmail) {
        System.out.println("Booking confirmation sent to " + userEmail);
    }
}
 
// Service class for managing loyalty/reward points
class LoyaltyPointsService {
    public void addPoints(String accountId, int points) {
        System.out.println(points + " loyalty points added to account " + accountId);
    }
}
 
// Service class for generating movie tickets
class TicketService {
    public void generateTicket(String movieId, String seatNumber) {
        System.out.println("Ticket generated for movie " + movieId + ", Seat: " + seatNumber);
    }
}
 
// ========== The MovieBookingFacade class ==============
class MovieBookingFacade {
    private PaymentService paymentService;
    private SeatReservationService seatReservationService;
    private NotificationService notificationService;
    private LoyaltyPointsService loyaltyPointsService;
    private TicketService ticketService;
 
    // Constructor to initialize all the subsystem services.
    public MovieBookingFacade() {
        this.paymentService = new PaymentService();
        this.seatReservationService = new SeatReservationService();
        this.notificationService = new NotificationService();
        this.loyaltyPointsService = new LoyaltyPointsService();
        this.ticketService = new TicketService();
    }
 
    // Method providing a simplified interface for booking a movie ticket
    public void bookMovieTicket(String accountId, String movieId, String seatNumber, String userEmail, double amount) {
        paymentService.makePayment(accountId, amount);
        seatReservationService.reserveSeat(movieId, seatNumber);
        ticketService.generateTicket(movieId, seatNumber);
        loyaltyPointsService.addPoints(accountId, 50);
        notificationService.sendBookingConfirmation(userEmail);
 
        // Indicate successful completion of the entire booking process.
        System.out.println("Movie ticket booking completed successfully!");
    }
}
 
// ── Driver ──────────────────────────────────────────────
class Main {
    public static void main(String[] args) {
        // Booking a movie ticket manually (using facade)
        MovieBookingFacade movieBookingFacade = new MovieBookingFacade();
        movieBookingFacade.bookMovieTicket("user123", "movie456", "A10", "[email protected]", 500);
 
        System.out.println();
        System.out.println("GOOD DESIGN: the client makes one call - MovieBookingFacade orchestrates the five services.");
    }
}

The same idea in Python

class PaymentService:
    def make_payment(self, account_id: str, amount: float) -> None:
        print(f"Payment of ₹{amount} successful for account {account_id}")
 
 
class SeatReservationService:
    def reserve_seat(self, movie_id: str, seat_number: str) -> None:
        print(f"Seat {seat_number} reserved for movie {movie_id}")
 
 
class NotificationService:
    def send_booking_confirmation(self, user_email: str) -> None:
        print(f"Booking confirmation sent to {user_email}")
 
 
class LoyaltyPointsService:
    def add_points(self, account_id: str, points: int) -> None:
        print(f"{points} loyalty points added to account {account_id}")
 
 
class TicketService:
    def generate_ticket(self, movie_id: str, seat_number: str) -> None:
        print(f"Ticket generated for movie {movie_id}, Seat: {seat_number}")
 
 
class MovieBookingFacade:
    def __init__(self) -> None:
        self._payment_service = PaymentService()
        self._seat_reservation_service = SeatReservationService()
        self._notification_service = NotificationService()
        self._loyalty_points_service = LoyaltyPointsService()
        self._ticket_service = TicketService()
 
    def book_movie_ticket(
        self,
        account_id: str,
        movie_id: str,
        seat_number: str,
        user_email: str,
        amount: float,
    ) -> None:
        self._payment_service.make_payment(account_id, amount)
        self._seat_reservation_service.reserve_seat(movie_id, seat_number)
        self._ticket_service.generate_ticket(movie_id, seat_number)
        self._loyalty_points_service.add_points(account_id, 50)
        self._notification_service.send_booking_confirmation(user_email)
 
        print("Movie ticket booking completed successfully!")
 
 
# ── Driver ──────────────────────────────────────────────
if __name__ == "__main__":
    movie_booking_facade = MovieBookingFacade()
    movie_booking_facade.book_movie_ticket(
        "user123", "movie456", "A10", "[email protected]", 500
    )
 
    print()
    print("GOOD DESIGN: the client makes one call - MovieBookingFacade orchestrates the five services.")

How Facade Pattern Solves the Issue

By introducing MovieBookingFacade, we:

• Provide a simple, unified interface (bookMovieTicket()).
• Hide the complexity of internal service calls from the client.
• Reduce coupling, so changes in internal services don't affect the client.
• Centralize the workflow logic, making it easier to update and reuse.

When to use Facade Pattern?

You should use the Facade pattern when:

• Subsystems are complex: This means there are too many classes and too many dependencies within the system you are trying to simplify.
• You want to provide a simpler API for the outer world: The Facade acts as a simplified entry point, hiding the complexity from clients.
• You want to reduce coupling between subsystems and client code: By interacting with the facade, the client code becomes less dependent on the individual components of the subsystem.
• You want to layer your architecture cleanly: The Facade helps in organizing the system into distinct layers, making it more modular and understandable.

Advantages

A few advantages of using the Facade Pattern are:

• Lightweight coupling: It reduces the dependencies between the client and the subsystem.
• Flexibility: It allows the subsystem to evolve without impacting the client code.
• Simplifies client design: Clients interact with a single, simplified interface instead of multiple complex objects.
• Promotes layered architecture: It helps organize the system into distinct layers, improving maintainability and scalability.
• Better testability: Individual subsystem components can be tested independently, and the facade itself can be tested for its orchestration logic.

Disadvantages

A few disadvantages of using the Facade Pattern are:

• Fragile coupling: If the facade itself changes frequently, it can still lead to ripple effects on client code.
• Hidden complexity: While it simplifies the client's view, the underlying complexity of the subsystem still exists, just hidden. This can make debugging or understanding the full flow more challenging for developers working on the subsystem.
• Runtime errors: Errors originating from the complex subsystem might be harder to diagnose when only interacting through the facade.
• Difficult to trace: Debugging can be more challenging as the facade adds another layer of indirection.
• Violation of SRP (Single Responsibility Principle): A facade might take on too many responsibilities if it orchestrates a very large and diverse set of operations, potentially becoming a "god object."

Class Diagram

Composite Pattern

The Composite Pattern is a structural design pattern that allows you to compose objects into tree structures to represent part-whole hierarchies. It lets clients treat individual objects and compositions of objects uniformly.

Problem It Solves

The Composite Pattern solves the problem of treating individual objects and groups of objects in the same way. The main problem arises when:

• You want to work with a hierarchy of objects.
• You want the client code to be agnostic to whether it's dealing with a single object or a collection of them.

Understanding the Problem

Consider you are building the checkout service of an e-commerce application and you take the following approach as shown in the code below.

Code (Without Composite Pattern)

// ⚠️ ANTI-PATTERN — this is the version we are about to fix. Do not copy it.
import java.util.*;
 
// Represents a single product
class Product {
    private String name;
    private double price;
 
    public Product(String name, double price) {
        this.name = name;
        this.price = price;
    }
 
    public double getPrice() {
        return price;
    }
 
    public void display(String indent) {
        System.out.println(indent + "Product: " + name + " - ₹" + price);
    }
}
 
// Represents a bundle of products
class ProductBundle {
    private String bundleName;
    private List<Product> products = new ArrayList<>();
 
    public ProductBundle(String bundleName) {
        this.bundleName = bundleName;
    }
 
    public void addProduct(Product product) {
        products.add(product);
    }
 
    public double getPrice() {
        double total = 0;
        for (Product product : products) {
            total += product.getPrice();
        }
        return total;
    }
 
    public void display(String indent) {
        System.out.println(indent + "Bundle: " + bundleName);
        for (Product product : products) {
            product.display(indent + "  ");
        }
    }
}
 
// ── Driver ──────────────────────────────────────────────
class Main {
    public static void main(String[] args) {
        // Individual Items
        Product book = new Product("Book", 500);
        Product headphones = new Product("Headphones", 1500);
        Product charger = new Product("Charger", 800);
        Product pen = new Product("Pen", 20);
        Product notebook = new Product("Notebook", 60);
 
        // Bundle: Iphone Combo
        ProductBundle iphoneCombo = new ProductBundle("iPhone Combo Pack");
        iphoneCombo.addProduct(headphones);
        iphoneCombo.addProduct(charger);
 
        // Bundle: School Kit
        ProductBundle schoolKit = new ProductBundle("School Kit");
        schoolKit.addProduct(pen);
        schoolKit.addProduct(notebook);
 
        // Add to cart logic
        List<Object> cart = new ArrayList<>();
        cart.add(book);
        cart.add(iphoneCombo);
        cart.add(schoolKit);
 
        // Display Cart
        double total = 0;
        System.out.println("Cart Details:\n");
 
        for (Object item : cart) {
            if (item instanceof Product) {
                ((Product) item).display("  ");
                total += ((Product) item).getPrice();
            } else if (item instanceof ProductBundle) {
                ((ProductBundle) item).display("  ");
                total += ((ProductBundle) item).getPrice();
            }
        }
 
        System.out.println("\nTotal Price: ₹" + total);
        System.out.println("ANTI-PATTERN: List<Object> plus instanceof checks - Product and ProductBundle have no shared type.");
    }
}

Working of Code

• Product class represents a simple item with name and price.
• ProductBundle class represents a group of products bundled together.
• Both classes have methods to display and return their prices.
• In main(), individual products and bundles are created and added to the cart.
• The cart is a List