Design Patterns: Facade

(This Blog post is part of a collaborative work between Me and Mustapha El Idrissi, Consult his devTo page for more information: https://dev.to/appsbymuss)

What is the Facade Pattern

This Structural Pattern provides a simplified interface to a complex subsystem, making it easier to use by encapsulating the intricacies of the system behind a single, unified interface.

What's its purpose ?

• The Facade Pattern helps in reducing the complexity of interactions with a complex system by providing a higher-level interface that abstracts away the underlying details.
• It’s useful when you want to simplify communication with a subsystem, allowing clients to interact with the system in a more straightforward way without needing to understand its complexity.

Key Concepts

• Facade Class: The main class that provides a simplified interface to the client. It delegates client requests to the appropriate components within the subsystem.

• Subsystem Classes: The classes that represent the complex functionality of the system. These classes contain the actual implementation details and logic but are hidden from the client.

Example: Home Automation System

• these are Subsystem Classes

public class LightSystem
{
    public void TurnOnLights() => Console.WriteLine("Lights are on.");
    public void TurnOffLights() => Console.WriteLine("Lights are off.");
}

public class MusicSystem
{
    public void PlayMusic() => Console.WriteLine("Playing music.");
    public void StopMusic() => Console.WriteLine("Music stopped.");
}

public class SecuritySystem
{
    public void ArmSystem() => Console.WriteLine("Security system armed.");
    public void DisarmSystem() => Console.WriteLine("Security system disarmed.");
}

• This is the Facade Class

public class HomeAutomationFacade
{
    private LightSystem _lights;
    private MusicSystem _music;
    private SecuritySystem _security;

    public HomeAutomationFacade()
    {
        _lights = new LightSystem();
        _music = new MusicSystem();
        _security = new SecuritySystem();
    }

    public void LeaveHome()
    {
        _lights.TurnOffLights();
        _music.StopMusic();
        _security.ArmSystem();
        Console.WriteLine("Home is in 'leave' mode.");
    }

    public void EnterHome()
    {
        _security.DisarmSystem();
        _lights.TurnOnLights();
        _music.PlayMusic();
        Console.WriteLine("Home is in 'enter' mode.");
    }
}

• And this is the Test (aka Consumer class)

public static void TestFacade()
{
    HomeAutomationFacade homeSystem = new HomeAutomationFacade();

    homeSystem.EnterHome();

    homeSystem.LeaveHome();
}

The Good, The Bad and the Ugly

Advantages

• Simplifies the interface for interacting with complex subsystems, making it easier for clients to use.
• Reduces dependencies between clients and subsystems, promoting loose coupling.
• Encapsulates subsystem complexity, allowing for easier maintenance and understanding.

Disadvantages

• The facade can become a "God Object" if it tries to handle too many responsibilities.
• May hide system complexities that might be needed for advanced usage.
• Over-simplifying can lead to limitations in functionality for clients needing deeper access.

When to not use

• When a subsystem is simple enough that no facade is needed.
• If clients require direct access to the components of a subsystem for customization or extension.
• In cases where the added layer of abstraction complicates the system rather than simplifying it.