Facade Design Pattern

The Facade Design Pattern is a structural pattern that provides a simple and unified interface to a complex subsystem. It hides the internal complexity of the system, making it easier to use and maintain.

• Structuring a system into subsystems helps reduce overall complexity and improves organization. A common design goal is to minimize communication and dependencies between these subsystems.
• The Facade Pattern achieves this by introducing a facade object that acts as a single entry point, providing a simplified interface to the underlying subsystem functionality.

Example: In a home automation system, a user controls lights, AC, and security cameras using a single app or panel. The control system acts as a Facade, hiding the complexity of multiple devices. It provides one simple interface to manage all subsystems efficiently.

In the above diagram:

• Multiple clients (Client A, B, C) interact only with the Facade instead of directly accessing subsystem classes.
• The Facade provides a simple method (like doSomething()) and internally coordinates with different subsystem packages.
• Subsystem classes (Package 1–4) handle actual processing, while the Facade hides their complexity from the clients.

Note: Facade Method Design Pattern provides a unified interface to a set of interfaces in a subsystem. Facade defines a high-level interface that makes the subsystem easier to use.

Real Life applications

The Facade Pattern is commonly used to provide a simplified interface to complex subsystems in real-world applications.

• Home Automation Systems: Provides a single interface to control lighting, heating, and security systems while hiding the complexity of multiple underlying subsystems.
• Video Streaming Platforms: Offers a unified interface for encoding, buffering, and video playback, simplifying interaction with complex media processing components.
• Banking Systems: Exposes simple methods for balance checks and fund transfers while concealing complex backend operations from the client.

Components

The Facade Pattern consists of key components that help simplify interactions with complex systems.

Consider for example a programming environment that gives applications access to its compiler subsystem.

• This subsystem contains classes such as Scanner,Parser, ProgramNode, BytecodeStream, and ProgramNodeBuilder that implement the compiler.
• Compiler class acts as a facade: It offers clients a single, simple interface to the compiler subsystem.
• It glues together the classes that implement compilerfunctionality without hiding them completely.
• The compiler facade makes life easier for most programmers without hiding the lower-level functionality from the few that need it.

1. Facade (Compiler)

Provides a simplified interface to interact with the complex compiler subsystem.

• Facade knows which subsystem classes are responsible for a request.
• It delegate client requests to appropriate subsystem objects.

2. Subsystem classes (Scanner, Parser, ProgramNode, etc.)

These classes perform the core functionality of the compiler system.

• Implements subsystem functionality and handles the tasks assigned by the Facade object.
• Has no knowledge of the Facade, meaning it does not maintain any reference to it.

3. Interface

Defines the set of high-level operations that the client can use.

• The Interface in the Facade Design Pattern refers to the set of simplified methods that the facade exposes to the client.
• It hides the complexities of the subsystem, ensuring that clients interact only with high-level operations, without dealing with the underlying details of the system.

Working

The facade acts as a single entry point that coordinates and delegates requests to multiple subsystem classes.

• Client interacts only with the Facade class instead of multiple subsystem classes.
• Facade internally calls the required methods of different subsystems.
• Subsystem classes remain unchanged and unaware of the facade.
• The facade simplifies complex workflows into easy-to-use operations.

Uses

The Facade Pattern is used to provide a simplified and unified interface to complex subsystems, making them easier for clients to use.

• Simplifies interaction with complex external systems such as databases or third-party APIs by hiding internal details.
• Helps in layering subsystems by defining clear boundaries and offering simple interfaces for each layer.
• Provides a single unified interface to multiple or diverse systems, improving usability and consistency.
• Shields client code from changes in internal implementations, reducing dependency and maintenance effort.

Implementation Example

Problem Statement:

Consider a hotel where multiple restaurants serve different types of food such as veg, non-veg, and mixed options. As a customer, you don’t interact with each restaurant directly or know their menus. Instead, you communicate with the hotel keeper, who understands the system and fetches the required menu for you. This simplifies your interaction by providing a single point of access to multiple services.

This example shows the practical application of the design pattern using code.

1. Interface of Hotel

package structural.facade;

public interface Hotel {
    public Menus getMenus();
}

package structural.facade;

public interface Hotel {
    public Menus getMenus();
}

from abc import ABC, abstractmethod

class Hotel(ABC):
    @abstractmethod
    def get_menus(self):
        pass

// JavaScript does not have interfaces, but we can simulate one using a class with abstract methods
class Hotel {
    getMenus() {
        throw new Error("Method getMenus() must be implemented.");
    }
}

Note : The hotel interface only returns Menus. Similarly, the Restaurant are of three types and can implement the hotel interface. Let’s have a look at the code for one of the Restaurants.

2. NonVegRestaurant

package structural.facade;

public class NonVegRestaurant implements Hotel {

    public Menus getMenus()
    {
        NonVegMenu nv = new NonVegMenu();
        return nv;
    }
}

package structural.facade;

public class NonVegRestaurant implements Hotel {

    public Menus getMenus()
    {
        NonVegMenu nv = new NonVegMenu();
        return nv;
    }
}

from structural.facade import Hotel, Menus, NonVegMenu

class NonVegRestaurant(Hotel):

    def get_menus(self):
        nv = NonVegMenu()
        return nv

class NonVegRestaurant {
    getMenus() {
        let nv = new NonVegMenu();
        return nv;
    }
}

3. VegRestaurant

package structural.facade;

public class VegRestaurant implements Hotel {

    public Menus getMenus()
    {
        VegMenu v = new VegMenu();
        return v;
    }
}

package structural.facade;

public class VegRestaurant implements Hotel {
    public Menus getMenus() {
        VegMenu v = new VegMenu();
        return v;
    }
}

class VegRestaurant:
    def getMenus(self):
        v = VegMenu()
        return v

class VegRestaurant {
    getMenus() {
        let v = new VegMenu();
        return v;
    }
}

4. VegNonBothRestaurant

package structural.facade;

public class VegNonBothRestaurant implements Hotel {

    public Menus getMenus()
    {
        Both b = new Both();
        return b;
    }
}

package structural.facade;

public class VegNonBothRestaurant implements Hotel {
    public Menus getMenus() {
        Both b = new Both();
        return b;
    }
}

class VegNonBothRestaurant:
    def getMenus(self):
        b = Both()
        return b

class VegNonBothRestaurant {
    getMenus() {
        let b = new Both();
        return b;
    }
}

Now consider the facade Design Pattern with the help of code:

1. HotelKeeper 

/*package whatever //do not write package name here */

#include <iostream>
using namespace std;

class VegMenu {};
class NonVegMenu {};
class Both {};

class HotelKeeper {
public:
    virtual VegMenu getVegMenu() = 0;
    virtual NonVegMenu getNonVegMenu() = 0;
    virtual Both getVegNonMenu() = 0;
};

/*package whatever //do not write package name here */

package structural.facade;

public interface HotelKeeper {
  
  public VegMenu getVegMenu();
  public NonVegMenu getNonVegMenu();
  public Both getVegNonMenu();
}

"""package whatever //do not write package name here """ 

from abc import ABC, abstractmethod

class HotelKeeper(ABC):

    @abstractmethod
    def getVegMenu(self):
        pass

    @abstractmethod
    def getNonVegMenu(self):
        pass

    @abstractmethod
    def getVegNonMenu(self):
        pass

/*package whatever //do not write package name here */

// Assuming the existence of classes VegMenu, NonVegMenu, and Both

class HotelKeeper {
  getVegMenu() {
    throw new Error("Method not implemented.");
  }
  getNonVegMenu() {
    throw new Error("Method not implemented.");
  }
  getVegNonMenu() {
    throw new Error("Method not implemented.");
  }
}

2. HotelKeeper Implementation

package structural.facade;

public class HotelKeeperImplementation implements HotelKeeper {

    public VegMenu getVegMenu()
    {
        VegRestaurant v = new VegRestaurant();
        VegMenu vegMenu = (VegMenu)v.getMenus();
        return vegMenu;
    }

    public NonVegMenu getNonVegMenu()
    {
        NonVegRestaurant v = new NonVegRestaurant();
        NonVegMenu NonvegMenu = (NonVegMenu)v.getMenus();
        return NonvegMenu;
    }

    public Both getVegNonMenu()
    {
        VegNonBothRestaurant v = new VegNonBothRestaurant();
        Both bothMenu = (Both)v.getMenus();
        return bothMenu;
    }
}

package structural.facade;

public class HotelKeeperImplementation implements HotelKeeper {

    public VegMenu getVegMenu()
    {
        VegRestaurant v = new VegRestaurant();
        VegMenu vegMenu = (VegMenu)v.getMenus();
        return vegMenu;
    }

    public NonVegMenu getNonVegMenu()
    {
        NonVegRestaurant v = new NonVegRestaurant();
        NonVegMenu NonvegMenu = (NonVegMenu)v.getMenus();
        return NonvegMenu;
    }

    public Both getVegNonMenu()
    {
        VegNonBothRestaurant v = new VegNonBothRestaurant();
        Both bothMenu = (Both)v.getMenus();
        return bothMenu;
    }
}

from abc import ABC, abstractmethod

class HotelKeeper(ABC):
    @abstractmethod
    def getVegMenu(self):
        pass

    @abstractmethod
    def getNonVegMenu(self):
        pass

    @abstractmethod
    def getVegNonMenu(self):
        pass

class VegRestaurant:
    def getMenus(self):
        return VegMenu()

class NonVegRestaurant:
    def getMenus(self):
        return NonVegMenu()

class VegNonBothRestaurant:
    def getMenus(self):
        return Both()

class HotelKeeperImplementation(HotelKeeper):

    def getVegMenu(self):
        v = VegRestaurant()
        vegMenu = v.getMenus()
        return vegMenu

    def getNonVegMenu(self):
        v = NonVegRestaurant()
        nonVegMenu = v.getMenus()
        return nonVegMenu

    def getVegNonMenu(self):
        v = VegNonBothRestaurant()
        bothMenu = v.getMenus()
        return bothMenu

class VegMenu:
    pass

class NonVegMenu:
    pass

class Both:
    pass

class HotelKeeper {
    getVegMenu() {
        throw new Error('Method not implemented.');
    }
    getNonVegMenu() {
        throw new Error('Method not implemented.');
    }
    getVegNonMenu() {
        throw new Error('Method not implemented.');
    }
}

class VegRestaurant {
    getMenus() {
        return new VegMenu();
    }
}

class NonVegRestaurant {
    getMenus() {
        return new NonVegMenu();
    }
}

class VegNonBothRestaurant {
    getMenus() {
        return new Both();
    }
}

class HotelKeeperImplementation extends HotelKeeper {

    getVegMenu() {
        let v = new VegRestaurant();
        let vegMenu = v.getMenus();
        return vegMenu;
    }

    getNonVegMenu() {
        let v = new NonVegRestaurant();
        let nonVegMenu = v.getMenus();
        return nonVegMenu;
    }

    getVegNonMenu() {
        let v = new VegNonBothRestaurant();
        let bothMenu = v.getMenus();
        return bothMenu;
    }
}

class VegMenu {}
class NonVegMenu {}
class Both {}

Note: From this, It is clear that the complex implementation will be done by HotelKeeper himself. The client will just access the Hotel Keeper and ask for either Veg, NonVeg or VegNon Both Restaurant menu.

How will the client program access this facade? 

package structural.facade;

public class Client
{
    public static void main (String[] args)
    {
        HotelKeeper keeper = new HotelKeeperImplementation();
        
        VegMenu v = keeper.getVegMenu();
        NonVegMenu nv = keeper.getNonVegMenu();
        Both = keeper.getVegNonMenu();

    }
}

package structural.facade;

public class Client
{
    public static void main (String[] args)
    {
        HotelKeeper keeper = new HotelKeeperImplementation();
        
        VegMenu v = keeper.getVegMenu();
        NonVegMenu nv = keeper.getNonVegMenu();
        BothMenu both = keeper.getVegNonMenu();
    }
}

from structural.facade import HotelKeeperImplementation, VegMenu, NonVegMenu, BothMenu

def main():
    keeper = HotelKeeperImplementation()
    v = keeper.get_veg_menu()
    nv = keeper.get_non_veg_menu()
    both = keeper.get_veg_non_menu()

if __name__ == "__main__":
    main()

const { HotelKeeperImplementation, VegMenu, NonVegMenu, BothMenu } = require('./structural/facade');

function main() {
    const keeper = new HotelKeeperImplementation();
    const v = keeper.getVegMenu();
    const nv = keeper.getNonVegMenu();
    const both = keeper.getVegNonMenu();
}

main();

In this way, the implementation is sent to the facade. The client is given just one interface and can access only that. This hides all the complexities.

Advantages

The Facade Pattern simplifies interaction with complex systems by providing a unified and easy-to-use interface.

• Simplified Interface: Provides a clear interface while hiding system complexities.
• Reduced Coupling: Minimizes client dependency on system internals and promotes modularity.
• Encapsulation: Shields clients from subsystem changes by wrapping complex interactions.
• Improved Maintainability: Enables easier system changes, refactoring, and extensions without affecting clients.

Disadvantages

While useful, the Facade Pattern can introduce limitations and additional abstraction in certain scenarios.

• Increased Complexity: Adds another abstraction layer, making code harder to understand and debug.
• Reduced Flexibility: Limits direct access to specific subsystem functionalities.
• Overengineering: Can add unnecessary complexity in simple systems.
• Potential Performance Overhead: Extra indirection may impact performance in critical scenarios.