Design Patterns in the Test of Time: Façade
A façade is an object that provides a simplified interface to a larger body of code, such as a class library.
The intent of the façade was good: to wrap APIs that are poorly designed in something shiny and nice.
In the real world, however, it is an evil pattern that is used to needlessly add abstractions for no particular reason. For example, look at this article.
That sound you just heard is your architecture, it is hiding in the closet, weeping silent tears about emotional and physical abuse that just doesn’t end.
I have yet to see a real case were façade was actually used properly. In most cases, people built a façade because That Is How We Do Things. And because of that, they ended up with things like the one above. It adds exactly nothing, and it horrifyingly complicates the code.
Recommendation: Avoid this, you really don’t need to do this most of the time, and most implementations are bad.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Claude Lalyre replied on Fri, 2012/11/23 - 4:11am
From my point of view I was thinking that a Facade should simplify an interface by reducing the number of methods... For example, I have an object A with 25 methods, and I create an object AFacade with just 1 or 2 methods... That was my understanding of that Pattern... Maybe I am wrong....
Johan Sjöberg replied on Fri, 2012/11/23 - 6:36am
I feel that the every time one of these design patterns have been rejected it's been due to the wrong reason. "Avoid because my collegues implements it wrong" is not a good reason. Wrongly implemented, ALL design patterns are bad.
A facade is meant to simplify. Consider a robot. Getting it to start/move/do tasks could be really complex underneath; starting an engine, handling the gyro and so on. A facade can be used to provide a simple interface to do complex operations.