The façade pattern is one of my most used patterns. It works as the glue both within an application and as a boundary to dependencies.
It mainly comes in handy when solving the following problems:
- Fluid design and readable APIs
- Protection against external forces and changes
Ever so often test driving development becomes extremely expensive because the interfaces the code depends on is impossible to test against. This may just as well be internal legacy libraries as external libraries. To remedy the problem I use a façade interface that provides the operations I need. I then mock the expected behaviour of the operations when writing code required. With some careful planing the binding of the library implementation to my façade can then be done without to much hassle.
Fluid design and readable APIs
Each component within an application strives to resolve it's own domain. This often results in the boundaries becoming a bit awkward. To help creating fluidity in design and APIs it is therefore often useful to create façades matching each domains language and a thin layer of bindings that glues the libraries together.
Protection against external forces and changes
When using external libraries, apart from the above issues with testability and fluidity, façades also help reduce the cost of upgrading the dependencies. Whenever an external library changes the only code in the application that will need to change is the binding to the façade.
The overhead for getting the above benefits is actually remarkably low. It is usually enough to create an interface that delegates it's operations to the library it is a façade for. The binding can the be done using dependency injection or factories.
Even when it's more difficult it's usually only a matter of composition. I have some times had to compose the the logic of the integration on a couple of abstraction levels but then it has still been well worth it since it has simplified the usage of the API considerably.
It is a shame that I don't get to see this pattern used more often. It would have reduced cost and complexity on many occasions.