WHAT’S IN THIS CHAPTER?            

• An introduction to the intent of the façade pattern
• A brief discussion of the benefits that the pattern brings
• Three ways that the pattern can be implemented: POJO, stateless, and stateful session bean façade
• The important differences between the stateful and the stateless session bean façade
• When and where to use this pattern
• Warnings about its use and potential pitfalls

WROX.COM CODE DOWNLOADS FOR THIS CHAPTER

The wrox.com code downloads for this chapter are found at www.wrox.com/go/projavaeedesignpatterns on the Download Code tab. The code is in the Chapter 3 download and individually named according to the names throughout the chapter.

The façade pattern is one of the structural design patterns described in the GoF¹ book. The intent behind it is to encapsulate complicated business logic in a higher-level interface that makes access to a subsystem easier to use. This is often done by grouping related method calls and invoking them sequentially from one method.

From a higher-level view, every API can be considered an implementation of the façade pattern since they provide a simple interface which hides its complexity. Any call to an API’s method results in the invocation of many other methods from a subsystem hidden behind it. An example of a façade would be the javax.servlet.http.HttpSession interface. This hides the complicated logic associated with maintaining the session while exposing its functionality via a handful of simple-to-use methods.

WHAT IS A FAÇADE?

The GoF¹ book describes this pattern as “providing a unified interface to a set of interfaces in a subsystem.” Head First Design Patterns² gives the same explanation and points out that, while hiding the complexity of the subsystem, the façade pattern offers the full power of the subsystem via an easier-to-use interface.

To give a basic real-world example of how the façade pattern works, imagine a washing machine with only two wash modes: heavily soiled and lightly soiled. For each mode, the washing machine must execute a predefined set of operations: set water temperature, heat water, set duration of wash cycle, set duration of spin cycle, add detergent, add bleach, add fabric softener, and so on. Each mode requires a different set of washing instructions (different amounts of detergent, higher or lower temperature, longer or shorter spin durations, and so on).

The simple interface provides two wash modes that hide the complicated logic of selecting the appropriate water temperature, the duration of the spin and wash cycle, and the different methods for adding detergent, bleach, or fabric softener. The user of the washing machine does not have to think about the complicated logic of how to wash the clothes (decide the temperature, cycle duration, and so on). The only decision the user must make is whether the clothes are heavily soiled or lightly soiled. This is in essence the façade pattern applied to a washing machine design. Later on in this chapter, you will see an implementation of this use case.

The façade pattern is commonly implemented for the following purposes and situations:

• Provide a simple and unified access to a legacy back-end system.
• Create a public API to classes, such as a driver.
• Offer coarse-grained access to available services. Services are combined, such as in the washing machine example.
• Reduce network calls. The façade makes many calls to the subsystem, while the remote client makes only one call to the façade.
• To encapsulate flow and inner details of an app for security and simplicity.

Façade Class Diagram

As can be seen in the class diagram in Figure 3.1, the façade pattern provides a simple interface to an underlying system. It encapsulates the complicated granular logic.

IMPLEMENTING THE FAÇADE PATTERN IN PLAIN CODE

Implementing the façade pattern isn’t complicated. It doesn’t enforce a strict structure or rule set. Any method that provides easy access to a complicated flow could be considered an implementation of the façade pattern.

Now you’ll implement the washing machine example given in the introduction as shown in Listing 3-1. You need two methods—heavilySoiled and lightlySoiled—that represent the two washing modes. All complicated work (the selection of water temperature, spin cycle duration, decision to add bleach or not) is performed in methods invoked from within the façade.

If you want to use this functionality, just invoke the façade’s lightlySoilded or heavilySoilded method and let it do the complicated logic of washing the clothes. All complicated logic is kept hidden by the façade and exposed via its two methods.

The implementation of the methods is decoupled from the client. This decoupling allows the implementation to change without affecting any change in the way the client accesses the washing services. The client knows nothing about the implementation of these methods, and it doesn’t care. All that it is interested in is obtaining the service it requires.

This example demonstrates one of many of the benefits of the façade pattern. This book does not go into detail about the benefits of the façade pattern, so what follows is a brief summary of the most important ones:

• A reduction in coupling because the client knows nothing about the subsystem
• Increased maintainability and manageability when changes are required
• Reuse of functionality because it encourages the reuse of controls and fine-grained logic
• Consistency of service execution by invoking the same method consistently from one invocation to the next
• Reduction in business logic complexity by grouping related methods and invoking them from one method invocation
• Centralization of security and transaction control management
• Testable and mockable pattern implementations

IMPLEMENTING THE FAÇADE PATTERN IN JAVA EE

Unlike many other patterns described in this book, Java EE does not offer a built-in implementation of this method. Nevertheless, it is straightforward to implement using stateful or stateless EJB. Using EJB offers the advantage of easy access to other EJB that the façade might require.

WHERE AND WHEN TO USE THE FAÇADE PATTERN

The façade pattern should be used to encapsulate complicated (business) logic at a high level and provide a cleaner single point of access via an API.

Whenever you are in the position to provide an interface or an API to someone, think first about the complexity of the logic and the changes that might occur. The façade pattern does a good job of providing a clean API while hiding the parts subject to change.

However, unnecessarily wrapping methods in a façade is bad practice and adds unnecessary layers. Premature encapsulation could result in too many invocations and layers that don’t add value.

When implementing the session façade, you must determine if the use case requires state to be maintained. A use case that invokes only one method of the façade to receive the service that it needs is considered nonconversational, so there is no need to save the conversational state between one method invocation and the next. You should implement this façade as a stateless session bean.

On the other hand, if the conversational state must be maintained between method invocations, the most appropriate way to implement the façade is as a stateful session bean.

You must be careful in the use of the stateful session façade because it ties up server resources until the client that provoked the conversation releases them or times out. This could mean that, for the majority of the time the stateful session bean façade is bound to the client, it is doing nothing; it’s just maintaining state and using resources. And, unlike stateless session bean façades, it cannot be reused and shared between other clients because each request creates a new instance of the stateless façade, maintaining the state for that client’s session.

So take care when using this pattern. Analyze the use case and make appropriate decisions.

SUMMARY

You can implement the façade pattern as a POJO, a stateless session bean, or a stateful session bean. The various ways to implement the façade pattern solve different problems for different use case scenarios. But the variety of implementations does not distract from its principle intent: providing a high-level simple interface to a more complicated subsystem.

Take care when deciding to implement the façade as a stateful session bean to ensure that it will not cause resource consumption issues.

A well-designed application makes good use of the façade pattern to encapsulate complicated logic and decouple subsystems from clients; however, the premature and overuse of the façade pattern can lead to a more complicated system with multiple layers.

The session façade pattern is akin to the boundary in the entity-control-boundary architectural pattern, and it is related to the adapter and wrapper patterns.