Design patterns: Facade

Facade design pattern

 
Facade pattern is a good design pattern when there is a large system with large number of interdependent classes.
This pattern helps us to hide the complexities of the large system and provide a simple interface for the client applications. Its wrapper class used to hide the implementation details.
 
Let’s take an example of ‘Production support team’ activities.
 
The client is reporting an issue and raising a problem ticket. The issue probably is described in one line.
The issue will be assigned to the support person and he/she will identify the root cause and will provide a workaround after a while.
 
Most of the case the client doesn’t care/ doesn’t wants to know what are the steps followed to identify the issue, who worked on it, how many teams involved, and how many test cases we used to test the workaround. Only client wants is the issue to be fixed ASAP.
 
Please have a look into the below diagram of production support team
Facade design pattern
In the above the diagram, the client may be a user who created a ticket to report an issue.
 
The Facade will provide various simplified access to the support services from the interdependent subsystems which are considered as complicated.
 
Subsystems are hidden from the client. Client may doesn’t have direct access to the subsystems (for example)
 
Let’s see the code example below;
 
Sub Systems
 
Here the 2 classes sees independent first as they can do certain tasks individually.

  1. using System;
  2. namespace facade
  3. {
  4.    class Support_SubSytem
  5.    {
  6.       public void connectSession() { Console.WriteLine("Support Session Connected"); }
  7.       public void sendSummary() { Console.WriteLine("Support send summary");
  8.       public void escalateRRT() { Console.WriteLine("escalate to RRT"); }
  9.       public void resolve() { Console.WriteLine("Resolve the issue"); }
  10.    }
  11.   
  12.    class RRT_SubSystem
  13.    {
  14.       public void connectSession() { Console.WriteLine("RRT Session Connected"); }
  15.       public void sendSummary() { Console.WriteLine("RRT send summary"); }
  16.       public void debugCode() { Console.WriteLine("debug Code"); }
  17.       public void escalateDEV() { Console.WriteLine("escalate to DEV"); }
  18.    }
Facade
 
In our example, façade class has the activities that we will perform to fix the issues.
 
In order to fix the issue we may need to follow a specific sequence of activities.
  1. class Ticket_Facade
  2. {
  3.    Support_SubSytem supportsystem = new Support_SubSytem();
  4.    RRT_SubSystem rrtsubsystem = new RRT_SubSystem();
  5.    public void fixMyIssue()
  6.    {
  7.       /*sequence of calls to interdependent subsystems*/
  8.       supportsystem.connectSession();
  9.       supportsystem.sendSummary();
  10.       supportsystem.escalateRRT();
  11.       rrtsubsystem.debugCode();
  12.       rrtsubsystem.connectSession();
  13.       rrtsubsystem.sendSummary();
  14.       supportsystem.resolve();
  15.    }
  16. }
Main function
 
The main function act as the client and it can be used to call the fixMyIssue() in the Ticket_Facade class

  1. class Client  
  2. { 
  3.    static void Main(string[] args)
  4.    {
  5.       Ticket_Facade facade = new Ticket_Facade();
  6.       Console.WriteLine("Facade Example\n----------------");
  7. /*simple for the client.
  8. No need to know the order and dependencies of the methods */
  9.       facade.fixMyIssue();
  10.       Console.ReadKey();
  11.    }
OUTPUT