Facade Pattern

Facade is known pattern for communication layer between system parts. Facades are classes that provide often simplified access to subsystems functionalities but they don’t set any limitations for using subsystem classes directly. Facades can be found from many API-s in different forms, This posting is quick introduction to Facade Pattern.

Definition

Facade Pattern provides a unified interface to a set of interfaces in subsystems. Facade defines a higher-level interface that makes the subsystem easier to use.
p. 185, Design Patterns, Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Jonhson, Johb Vlissides.

Although the definition may sound complex, the idea of Facade Pattern is still simple:

Using Facade Pattern

Facade Pattern – like any other pattern – is not silver bullet and it’s not cure for every disease. Consider using facade in this situations:

Providing simple interface to complex subsystems. API-s often come with deep technical knowledge about problem space and it’s not easy to get started with them. Deep structure of classes, a lot of unknown terms and strange ideas behind implementation details – all these “problems” are there to make sure that API reflects business domain better and lives long life with not much breaking changes between versions. Still there are use cases like “place order”, “calculate credit rating” etc that can be implemented behind simple interface. This is where facade classes come in. You can provide simple interface to client code and hide complexities to facade classes.

Avoiding growing number of dependencies. Subsystems can be complex, have many classes and many dependencies between these classes. When using subsystem classes directly our code has also more and more dependencies to its classes. Facade class with simple public interface stops the growth of dependencies in client code and hides the growing rocket science behind it.

Internal layering. Facade classes can be used also internally to make interfacing between subsystems easier. Actually we solve same problems state above in internal context.

Facade Pattern in business applications

In business applications I’m using Facade Pattern very often. Public classes in Service Layer provide simplified interface to run use cases so client applications doesn’t have to know about internals of Domain Model. Also in well written systems with web services you can see how web services are just facade layer between clients and actual system logic.

Don’t consider facade as just one class – this way you end up easily with huge gonzo-classes with huge public interface.

NB! Do handle facade classes with constant care and pay a lot of attention to them. These classes are often the most important communication layer in system and by letting these classes to rot you spread the disease also to all client applications. Once it happens there is no easy way back because you have to make changes to different systems and don’t expext external systems be under you control.

You can apply elements of API building here to get good public interface but you can take it more easily because anyway your facade classes communicate all requests to service layer.

Abusing Facade Pattern

During my carreer I have seen different implementations of facades. Some implementations are very good – a lot of complex stuff is suddenly easier to use and changes to subsystem classes only boil up to facade. But there have also been disastrous implementations.

In one project there was huge class called BusinessFacade with following problems:

• over 5500 lines of code,
• enormous amount of dependencies to other classes,
• huge number of methods,
• many lengthy methods,
• logic spread over this huge class and other classes behind it,
• not very communicative names of methods.

This kind of beast is not easy to use for front-end developers as they must be able to orient well in huge public interface. Often it was hard for them to decide what method is the right one to call and this, of course, caused some misbehaviors in system.

Wrapping up

Facade classes make it easier to use functionalities of subsystem classes. As facade has its own public interface it is the highest point that is reflected by changes to subsystem classes and dependencies between them. Adding facade classes to your system doesn’t introduce any restrictions for using subsystem classes directly although you can come out with policy like this. Be careful when designing facade classes because you don’t want them to get too big and messy. Carefully written facades help client code programmers to use complex functionalities without getting over flooded with details they don’t need to know.