Design Patterns Uncovered: The Facade Pattern

This article will focus on the Facade pattern. So far in our design patterns we’ve already looked at the Observer and Adapter patterns. Facade has some similarities with the Adapter, so it’s a logical next step in our series.

Facades in the Real World

Facades are all around us in the real world. Operating systems are one such example - you don’t see all the inner workings of your computer, but the OS provides a simplified interface to use the machine. Buildings also have a facade - the exterior of the building. Wikipedia gives us a nice link between software architecture and standard architecture:

In architecture, the facade of a building is often the most important from a design standpoint, as it sets the tone for the rest of the building

So, in a nutshell, a Facade aims to make things look cleaner and more appealling.

The Facade Pattern

Like the Adapter pattern, Facade is known as a structural pattern, as it’s used to identifying a simple way to realize relationships between entities. The definition of Facade provided in the original Gang of Four book on Design Patterns states:

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.

The diagram definition of the Facade pattern is quite simple - all you’re really doing is insulating client from the subsystem:

Like the adapter pattern, the Facade can be used to hide the inner workings of a third party library, or some legacy code. All that the client needs to do is interact with the Facade, and not the subsystem that it is encompassing.
The following sequence diagram illustrates how the pattern is used by a client:

Where Would I Use This Pattern?

As the concept behind facade is to simplify an interface, service oriented architectures make use of the facade pattern. For example, in web services, one web service might provide access to a number of smaller services that have been hidden from the caller by the facade. Similarly, a typical pattern in OSGi bundles is to provide an interface package that is exposed to users of the bundle. All other packages are hidden from the user.

So How Does It Work In Java?

Let’s put together a simple example in Java code to illustrate the pattern. Let’s take a travel agent site for example, that allows you to book hotels and flights. We have a HotelBooker:

public class HotelBooker
{

  public ArrayList<Hotel> getHotelNamesFor(Date from, Date to) 
  {
      //returns hotels available in the particular date range

  }

}

And a FlightBooker:

public class FlightBooker
{

  public ArrayList<Flight> getFlightsFor(Date from, Date to) 
  {
      //returns flights available in the particular date range

  }

}

Both of these have Hotel and Flight datatypes, which the client has knowledge about. They could be provided in the same package as the Facade for example.
The TravelFacade class allows the user to get their Hotel and Flight information in one call:

public class TravelFacade
{

   private HotelBooker hotelBooker;
   private FlightBooker flightBooker; 

  public void getFlightsAndHotels(Date from, Data to)
  {
         ArrayList<Flight> flights = flightBooker.getFlightsFor(from, to);
         ArrayList<Hotel> hotels = hotelBooker.getHotelsFor(from, to);

         //process and return

   }

}

All that the client needs to worry about is the Facade class:

public class Client
{

   public static void main(String[] args)
   {
        TravelFacade facade = new TravelFacade(); 
        facade.getFlightsAndHotels(from, to);
   }
}

As you can see, it’s just a simple approach to encapsulating data.

Watch Out for the Downsides

By introducing the Facade into your code, you will be hardwiring subsystems into the Facade. This is fine if the subsystem never changes, but if it does, your Facade could be broken. Therefore, developers working on the subsystem should be made aware of any Facade around their code.