Design Patterns: Façade Pattern

DZone 's Guide to

Design Patterns: Façade Pattern

Learn more about the Facade Pattern: what it is, useful things it can do, and pros and cons.

· Java Zone ·
Free Resource

The simple definition is that it hides the complex logic and provides an interface to the client. Sounds familiar? This is nothing much more than the core part of abstraction: one of the core principles of object orientation.

So what is special about this and why does it deserve its own name and place in the catalogue of design patterns?

It’s not merely about creating abstractions but creating a specific type of abstraction in an enterprise system. You will have a layer called the application layer that describes at a higher level what that part of your application/subsystem actually does. Think of this high-level use case. That would be described by a business analysis: make an order, get a list of products, and match a given search criteria.

That is really what you are doing with the façade, describing these high-level abstractions to any user above that layer, perhaps a GUI layer or remote service invocation, they are talking in very simplistic terms to the façade and telling it please do this: the underlining code for that would be non-trivial and fairly complex.

How do you do this in classic GoF fashion, it's really not very difficult at all, they are general assumed to be stateless objects often named service or façade and you create atomic methods that do a single thing. That is generally how it is implemented in GoF.

What does Java EE give you? In this case, Java EE has a specialized annotation, the annotation that I talked about before, that is the stateless annotation. It is essentially a marker to denote that this is a façade and that it is intended to be stateless and to describe atomic operations at the application layer.

It can do some very useful things.

public class BankServiceFacade{

 public void complexBusinessLogic(){
 // Very very complex logic

public BankServiceFacade service;

It is entirely thread-safe, when you access it, it will be thread safe but it is not a singleton. How it is made thread safe despite not being a singleton is beyond the scope of this talk but essentially it involves some container magic.

It is thread-safe and stateless, you will never run into thread safety problems, it is by default transactional and it is useful for that tier of your application as you would normally want those high-level use cases to be transactional, also it includes things like monitoring management as well as pooling and, more importantly, defining upper threshold for pool sizes for these services. It is very useful for defining high-level scalable APIs.

It is stateless in terms of what the API expectations are. The implementation may be using things that are stateful for example you might have an entity manager that connects to a database. The thread safety is to shield the implementation from any issue with thread safety concerns. Why does it need to be pooled? Very simply, this is essentially the backbone of your application. Let's assume that you have a createOrder method and let's assume that you get a sudden burst of orders and suddenly have 10,000 orders to process concurrently because this object has an implicit upper bound you won’t run into a thread starvation situation. It will only be processed within the upper bounds of that thread pool which is typically 10, 15, 100 threads.

The Good, Bad and the Ugly

The Good

Gives you a range of services which you can add on top: scheduling, remoting, asynchronous processing, you can publish it out as a SOAP webservice, websocket endpoint, REST endpoint.

The Bad

Overuse may introduce unnecessary layers if you don’t need it don’t introduce one.

The Ugly

There isn’t one really.

design pattern

Published at DZone with permission of Alex Theedom , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}