Design Patterns
Facade
SE516
Melisa Tyira
A design pattern describes a solution to a design problem that can be used over and over again. The key to the goal of a design pattern is the reuse of objects in order to avoid rework. The use of existing objects is a major factor towards software productivity.
A design pattern is described using the following elements: pattern name, problem, solution, and consequences. A pattern name is given to each design pattern in order to increase our vocabulary thus being able to discuss design patterns freely without having to give a description each time. The problem is a description of the design problem, which also leads to a description of when to apply the pattern. The solution is not a description of a specific design that will solve the problem but a description of the elements and interactions between these elements that make up the design. The consequences are the positive and negative results of applying a design pattern. It is beneficial to decide the pros and cons of applying a design pattern in order to determine if there are truly benefits to applying a design pattern.
There are many documented design patterns and groups of these design patterns are related in some way to one another. These groups of design patterns are: creational patterns, structural patterns, and behavioral patterns. I will discuss the Facade pattern which is classified as a structural pattern. Structural patterns are patterns that describe how classes and objects are structured within a larger structure. Structural patterns can either be structural class patterns or structural object patterns. Structural class patterns are concerned with inheritance in order to create interfaces or implementations. Structural object patterns are concerned with the composition of objects in order to create new functionality. Facade is an object structural pattern.
Facade is used to create common interfaces that interact with a subsystem of interfaces. This is used because it is less complex and easier for us than having multiple interfaces interact with a subsystem. A general template for a facade pattern is as follows:
The client classes access the Facade class, which accesses the subclasses. The Facade class minimizes the access to subsystem classes that the client classes are not concerned with. Otherwise, without the Facade class the client classes would access subsystem classes as shown in the following diagram:
The facade pattern is ideal to use when a simple interface is needed for a complex subsystem. The larger the subsystem gets, the more classes that are involved, which makes this easier to reuse and customize. This can also pose a problem by making it harder for clients that do not wish to customize the subsystem. If customization is needed, the facade should probably not be used. The facade is also used to reduce the coupling between the clients and subsystems, therefore, the subsystem is independent of the client classes and other subsystems. A facade pattern can also be used if there are multiple subsystems. Multiple facades can be created as an entry point into each subsystem. If two subsystems are dependent on one another, they can communicate through a facade.
A real-world example that explains the use of a facade is an ordering system. I have displayed the use of a facade between the client class and subclasses. A client runs a request that communicates with the facade class to delegate requests to the appropriate subsystem objects. In this case, order, inventory, and product are the subsystem classes.
This same design, not including the facade class would look like the following:
In this diagram, the client is responsible to determine which class is needed through the interface. The facade object allows for the client class to access the orders, inventory, and product subsystem classes by going through a common interface that determines for the client, which class is needed. This helps in solving the design problem because it is less complex for the client due to the fact that there are fewer interfaces for the client to deal with, thus reducing coupling.
In a more general sense, the facade is like a 9-1-1 operator. A client calls the 9-1-1 operator and the call is directed to the ambulance, hospital, police, etc. The clients are shielded from these departments and do not have direct access to them. The client uses the 9-1-1 operator to access these departments and the 9-1-1 operator will dispatch services as needed. This promotes weak coupling because in the event of a burglary, the fire department does not need to be contacted. This is how the facade design pattern works.
Each design pattern has similarities to other existing patterns and can sometimes be used in place of each other or along with other patterns. The abstract factory pattern can be used in place of, or along with the facade pattern. It can be used to provide an interface to creating classes in the subsystem or can be used to hide classes that are specific to a particular pattern. The mediator pattern is also similar to the facade pattern. The mediator pattern is used to encapsulate common behavior between classes. The mediator is responsible for controlling interactions between these objects thus reducing coupling and dependencies. This is similar to the facade pattern except for the fact that facade does not define new functionality and the subsystem classes do not know about the facade class like they do in the mediator pattern.
There are many benefits to using the facade design pattern. It allows clients to deal with less subsystem objects because requests are sent through the facade object and forwarded to the appropriate subsystem object. Clients do not have to access the subsystem objects directly. Weak coupling is promoted and dependencies are eliminated because there is no interaction between the client objects and the subsystem objects.
Code Example:
Classes
BackEndOne
BackEndTwo
Broker
Client
Interface
Backend
/**
* Creation date: (09/24/2002 8:50:54 AM)
* @author: Melisa
*/
interface BackEnd {
/**
* Insert the method's description here.
* Creation date: (09/24/2002 8:52:04 AM)
* @return java.lang.String
*/
String login();
}
/**
* Creation date: (09/24/2002 8:45:17 AM)
* @author: Melisa
*/
class BackEndOne implements BackEnd {
/**
* Creation date: (09/24/2002 8:48:21 AM)
*/
public BackEndOne()
{
}
/**
* Creation date: (09/24/2002 8:50:33 AM)
* @return java.lang.String
*/
public String login() {
return "backendone";
}
}
/**
* Creation date: (09/24/2002 8:45:43 AM)
* @author: Melisa
*/
class BackEndTwo implements BackEnd {
/**
* Creation date: (09/24/2002 8:48:10 AM)
*/
public BackEndTwo() {}
/**
* Creation date: (09/24/2002 8:49:54 AM)
* @return java.lang.String
*/
public String login() {
return "backendtwo";
}
}
/**
* Creation date: (09/24/2002 8:39:33 AM)
* @author: Melisa
*/
class Broker implements BackEnd{
public static final String BACKENDONE="BACKENDONE";
public static final String BACKENDTWO="BACKENDTWO";
private BackEnd localBackEnd=null;
/**
* Creation date: (09/24/2002 8:40:06 AM)
* @param backEndComponent java.lang.String
*/
public Broker(String backEndComponent) throws Exception
{
if(backEndComponent.equals(BACKENDONE))
{localBackEnd=new BackEndOne();}
else if(backEndComponent.equals(BACKENDTWO))
{localBackEnd=new BackEndTwo();}
else
{throw new Exception("comp not found");}
}
/**
* Creation date: (09/24/2002 8:49:09 AM)
* @return java.lang.String
*/
public String login() {
return localBackEnd.login();
}
}
/**
* Creation date: (09/24/2002 8:38:16 AM)
* @author: Melisa
*/
class Client {
/**
* Creation date: (09/24/2002 8:38:38 AM)
*/
public Client() {}
/**
* Creation date: (09/24/2002 8:38:49 AM)
* @param args java.lang.String[]
*/
public static void main(String[] args)
{
try{
Broker broker=new Broker(Broker.BACKENDONE);
System.out.println(broker.login());
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
This is an example of code that does not run but it will explain the use of a facade design pattern. The client class calls the broker class, which is the facade class. The broker class determines whether or not the client should access backendone or backendtwo. The client class is unaware of the methods of the facade class but still receives the output that was requested.
References
Gamma, Erich & Helm, Richard & Johnson, Ralph & Vlissides, Design Patterns: Elements of Reusable Object-Oriented Design
http://www.agcs.com/supportv2/techpapers/patterns/papers/tutnotes
http://www.agcs.com/supportv2/techpapers/patterns/papers/patexamples.htm
http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/tutorial.html
7