Facade Pattern in Design Patterns a Java Example

Facade pattern provides a unified interface to a set of interfaces in a subsystem. Let’s learn in detail about this pattern along with Java sample code.

 

Façade Pattern’s Intent

Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.

 

Façade Pattern’s Motivation

Structuring a system into subsystems helps reduce complexity. A common design goal is to minimize the communication and dependencies between subsystems. One way to achieve this goal is to introduce a facade object that provides a single, simplified interface to the more general facilities of a subsystem.

 

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. Some specialized applications might need to access these classes directly. But most clients of a compiler generally don’t care about details like parsing and code generation; they merely want to compile some code. For them, the powerful but low-level interfaces in the compiler subsystem only complicate their task.

 

To provide a higher-level interface that can shield clients from these classes, the compiler subsystem also includes a Compiler class. This class defines a unified interface to the compiler’s functionality. The Compiler class acts as a facade: It offers clients a single, simple interface to the compiler subsystem.

 

Façade Pattern’s Applicability

Use façade pattern :

• To provide a simple interface to a complex system.
• To decouple a subsystem from clients and other subsystems, thereby promoting system independence and portability.
• To define an entry point to each subsystem level. If subsystems are dependent, then the dependencies can be simplified by making them communicate with each other solely through their façade.

 

Façade Pattern’s Structure

The structure of façade pattern is shown below:

 

Participants

The participants in the façade pattern are:

• Façade: Knows which subsystem classes are responsible for a request. Delegates client requests to appropriate subsystem objects.
• Subsystem classes: Implement subsystem functionality. Handle work assigned by the Façade Have no knowledge of the Façade.

 

Collaborations

Clients communicate with the subsystem by sending requests to the Façade, which forwards them to the appropriate subsystem object.

 

Façade Pattern’s Consequences

The façade pattern offers the following benefits:

1. It shields clients from subsystem components, thereby reducing the number of objects that clients deal with and making the subsystem easier to use.

 

2. It promotes weak coupling between the subsystem and its clients. Often the components in a subsystem are strongly coupled. Weak coupling lets you vary the components of the subsystem without affecting its clients.

 

3. It doesn’t prevent applications from using subsystem classes if they need to. Thus you can choose between ease of use and generality.

 

Façade Pattern’s Implementation

Following issues should be considered when implementing façade pattern:

1. Reducing client-subsystem coupling: The coupling between clients and the subsystem can be reduced even further by making Facade an abstract class with concrete subclasses for different implementations of a subsystem. Then clients can communicate with the subsystem through the interface of the abstract Facade class. This abstract coupling keeps clients from knowing which implementation of a subsystem is used.

 

2. Public versus private subsystem classes: A subsystem is analogous to a class in that both have interfaces, and both encapsulate something—a class encapsulates state and operations, while a subsystem encapsulates classes. And just as it’s useful to think of the public and private interface of a class, we can think of the public and private interface of a subsystem.

 

Sample Code (Java Example)

Suppose we have an application with set of interfaces to use MySql/Oracle database and to generate different types of reports, such as HTML report, PDF report etc. So we will have different set of interfaces to work with different types of database.

 

Now a client application can use these interfaces to get the required database connection and generate reports. But when the complexity increases or the interface behavior names are confusing, client application will find it difficult to manage it. So we can apply Facade pattern here and provide a wrapper interface on top of the existing interface to help client application.

 

We can have two helper interfaces, namely MySqlHelper and OracleHelper.

//MySqlHelper.java
import java.sql.Connection;
 
public class MySqlHelper {
     
    public static Connection getMySqlDBConnection(){
        //get MySql DB connection using connection parameters
        return null;
    }
     
    public void generateMySqlPDFReport(String tableName, Connection con){
        //get data from table and generate pdf report
    }
     
    public void generateMySqlHTMLReport(String tableName, Connection con){
        //get data from table and generate pdf report
    }
}

 

//OracleHelper.java
import java.sql.Connection;
 
public class OracleHelper {
 
    public static Connection getOracleDBConnection(){
        //get MySql DB connection using connection parameters
        return null;
    }
     
    public void generateOraclePDFReport(String tableName, Connection con){
        //get data from table and generate pdf report
    }
     
    public void generateOracleHTMLReport(String tableName, Connection con){
        //get data from table and generate pdf report
    }
     
}

 

We can create a Facade interface like below. Notice the use of Java Enum for type safety.

//HelperFacade.java
import java.sql.Connection;
 
public class HelperFacade {
 
    public static void generateReport(DBTypes dbType, ReportTypes reportType, String tableName){
        Connection con = null;
        switch (dbType){
        case MYSQL: 
            con = MySqlHelper.getMySqlDBConnection();
            MySqlHelper mySqlHelper = new MySqlHelper();
            switch(reportType){
            case HTML:
                mySqlHelper.generateMySqlHTMLReport(tableName, con);
                break;
            case PDF:
                mySqlHelper.generateMySqlPDFReport(tableName, con);
                break;
            }
            break;
        case ORACLE: 
            con = OracleHelper.getOracleDBConnection();
            OracleHelper oracleHelper = new OracleHelper();
            switch(reportType){
            case HTML:
                oracleHelper.generateOracleHTMLReport(tableName, con);
                break;
            case PDF:
                oracleHelper.generateOraclePDFReport(tableName, con);
                break;
            }
            break;
        }
         
    }
     
    public static enum DBTypes{
        MYSQL,ORACLE;
    }
     
    public static enum ReportTypes{
        HTML,PDF;
    }
}

 

Here is the client program:

//FacadePatternTest.java
import java.sql.Connection;
 
import com.journaldev.design.facade.HelperFacade;
import com.journaldev.design.facade.MySqlHelper;
import com.journaldev.design.facade.OracleHelper;
 
public class FacadePatternTest {
 
    public static void main(String[] args) {
        String tableName="Employee";
         
        //generating MySql HTML report and Oracle PDF report without using Facade
        Connection con = MySqlHelper.getMySqlDBConnection();
        MySqlHelper mySqlHelper = new MySqlHelper();
        mySqlHelper.generateMySqlHTMLReport(tableName, con);
         
        Connection con1 = OracleHelper.getOracleDBConnection();
        OracleHelper oracleHelper = new OracleHelper();
        oracleHelper.generateOraclePDFReport(tableName, con1);
         
        //generating MySql HTML report and Oracle PDF report using Facade
        HelperFacade.generateReport(HelperFacade.DBTypes.MYSQL, HelperFacade.ReportTypes.HTML, tableName);
        HelperFacade.generateReport(HelperFacade.DBTypes.ORACLE, HelperFacade.ReportTypes.PDF, tableName);
    }
 
}

 

Façade Pattern’s Known Uses

Following are the examples in Java API where Façade pattern is used:

• faces.context.FacesContext, it internally uses among others the abstract/interface types LifeCycle, ViewHandler, NavigationHandler and many more without that the enduser has to worry about it (which are however overrideable by injection).
• faces.context.ExternalContext, which internally uses ServletContext, HttpSession, HttpServletRequest, HttpServletResponse, etc.

 

Related Patterns

Abstract Factory can be used with Facade to provide an interface for creating subsystem objects in a subsystem-independent way. Abstract Factory can also be used as an alternative to Facade to hide platform-specific classes.

 

Mediator is similar to Facade in that it abstracts functionality of existing classes. However, Mediator’s purpose is to abstract arbitrary communication between colleague objects, often centralizing functionality that doesn’t belong in any one of them. A mediator’s colleagues are aware of and communicate with the mediator instead of communicating with each other directly. In contrast, a facade merely abstracts the interface to subsystem objects to make them easier to use; it doesn’t define new functionality, and subsystem classes don’t know about it.

 

Usually only one Facade object is required. Thus Facade objects are often Singletons.

 

Non-Software Example

The Facade defines a unified, higher level interface to a subsystem, that makes it easier to use. Consumers encounter a Facade when ordering from a catalog. The consumer calls one number and speaks with a customer service representative. The customer service representative acts as a Facade, providing an interface to the order fulfillment department, the billing department, and the shipping department.