Understanding FACADE Pattern




FacedePattern1.jpg

Table of Contents

  1. Introduction
  2. Illustration
  3. Source Code Explanation
  4. Facade Alternatives

    • Transparent Facade
    • Opaque Facade
    • Static Facade
     
  5. When to APPLY Facade
  6. Summary

Introduction

What is the primary meaning of facade in general? Facade means the front of a building, especially a false or decorative one. In other words a building with a beautiful and facilitated entrance following many rooms that provide a greater living experience, In technical terms facade is an object that provides a simplified interface to access a large set of classes or a large set of features of the system. We can also say a facade is an entry point to access features in a structured way. The GOF book says the Facade Pattern should "Provide a unified interface to a set of interfaces in a system. It defines a high level interface that makes the subsystem easier to use".

Illustration

The role of a facade is to provide a high level view of various subsystems whose details are hidden from users.

FacedePattern2.jpg

The idea behind the Facade Pattern is that you do not want all classes of objects to know much about one another. As much as possible we should lock away the details inside each class using the Facade Pattern that tells one object that needs to know much about the other to make their coupling loose. Programmers always should use the loosest coupling. The Facade Pattern is used for an easier or simpler interface to an underlying implementation object.

Source Code Explanation

I hope you guys now have a broad view of what a Facade Pattern is. Now we will look much deeper in a technical perspective of how to apply a Facade Pattern in C# with an example. On the beginning of every month we need to think about the financial settlement. For example, say we need to pay our monthly mobile bills, electricity bills, and Loan dues and so on. We also need to receive the business amount if we are doing any business. Finally we will transfer the balance amount to our savings account. These are the routines things we need to perform every month.

FacedePattern3.jpg

The problem here is, every time you are about to do all the operations mentioned above.

ElectricityBillController EB_Pay = new ElectricityBillController();
GasBillController Gas_Pay = new GasBillController();
MobileBillController Mobile_Pay = new MobileBillController();
 LoanController Loan_Pay = new LoanController();
 IncomeFromShare Share_Recv = new IncomeFromShare();
 IncomeFromBuisness Buiss_Recv = new IncomeFromBuisness();
//Paying Electricty Bill
EB_Pay.PayTo();
//Paying Gas Bill
Gas_Pay.PayTo ();
//Paying Mobile bill
Mobile_Pay.PayTo ();
//Paying Loans
 Loan_Pay.PayTo ()
//Income from Shares
 Share_Recv.RecieveFrom ();
//Income from business
Buiss_Recv.RecieveFrom ();

The client must create objects for all the classes I mentioned above. Now I need to write myself a Facade Pattern application that will do the job for me internally. So I will create a Facade Pattern class that will expose methods, like "PayMyMonthlyBills()", "RecieveMyIncome()" and "TransferToSavings()". Every time I just simply need to call the preceding three methods that will take care of my financial statement every month. No worries. So we are going to apply the Facade Pattern in the following code.

Class Facade_Transactions
{
ElectricityBillController EB_Pay = new ElectricityBillController();
GasBillController Gas_Pay = new GasBillController();
MobileBillController Mobile_Pay = new MobileBillController ();
LoanController Loan_Pay = new LoanController();
 
IncomeFromShare Share_Recv = new IncomeFromShare();
IncomeFromBuisness Buiss_Recv = new IncomeFromBuisness();
TransferToSavings SavingsObj = new TransferToSavings();
 ///
<summary>
/// Function it pays monthly Electricity, Gas, Mobile and Loan dues
/// </summary>
Public void PayMyMonthlyBills ()
{
    //Paying Electricity Bill
    EB_Pay.PayTo();
    //Paying Gas Bill
    Gas_Pay.PayTo();
    //Paying Mobile bill
    Mobile_Pay.PayTo();
    //Paying Loans
    Loan_Pay.PayTo();
}
/// <summary>
///
Function it receives income from shares and business
/// </summary>
Public void RecieveMyIncome()
{
    //Income from Shares
    Share_Recv.RecieveFrom();
    //Income from business
    Buiss_Recv.RecieveFrom();
}
/// <summary>
///
Function it transfers savings to other account
/// </summary>
Public void TransfrToSavings ()
{
    //Transfr remaining to savings
    SavingsObj.TransferTo();
    Console.ReadLine();
}
}
Static void Main (string [] args)
{
    Facade_Transactions Transaction = new Facade_Transactions();
    Transaction.RecieveMyIncome ();
    Transaction.PayMyMonthlyBills ();
    Transaction.TransfrToSavings ();

So the implementation above is changed completely based on the following diagram:

FacedePattern4.jpg

The Facade Transaction stands in front and manages the entire subsystems.

The client will simply perform the following to do the monthly task.

Facade Alternatives

The following are some of the alternatives of the Facade Pattern:

  • Transparent Facade

  • Opaque Facade

  • Static Facade

Transparent Facade Pattern

One alternative is the Transparent Facade Pattern that makes all the subsystems public, in other words the client can access the subsystem directly. Refer to the attached source code in which you can assume that all the subsystem classes ElectricityBill, GasBill, MobileBill are public. Subsystem operations can be called directly as well as through the facade. That is why we call this a Transparent Facade.

Opaque Facade Pattern

Another alternative is a Opaque Facade Pattern, which means that none of the subsystems can be accessed except the Facade object. There is no direct access here. The attached sample is nothing but an opaque facade.

Static Facade Pattern

The last one is the Static Facade Pattern; no instantiation is necessary. The user interfaces with the facade class directly, such as Facade_Transactions.PayMyMonthlyBills ().

When to apply a facade:

  • When the system has several identifiable subsystems

  • The abstractions and implementations of a subsystem are tightly coupled

  • There is an entry point needed for each layered software

Summary

The Facade Pattern can be adopted when there is a greater number of identifiable subsystems that will be controlled by the facade object.

Refer to the attached source code for debugging purposes.