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.

The example shown in the referenced article is not really a facade, so the problem is with the example and not the pattern itself. I would consider something like WebClient or WebRequest class as a good example of facade. Imagine working with raw sockets, authentication, compression, caching and other stuff, instead of using it

@Charles Flatt I too think that View Model fits the pattern. But we should be careful when to use it.

I think it depends whether the actual interface of your application look exactly like the data structure you're using. If that is the case View Models and Facade bring no value. They just copy the data model.

However in most real applications, the interface of the application will almost never look like the data model, so View Models and Facade come in handy.

I was also thinking of ISession from NHibernate, which seems to me like a facade over the internal structure of NHibernate.

I think the main problem is that in the real world it is a pattern that is often misused and many things are incorrectly called a facade. A facade is supposed to provide a simplified interface over things like a library. In the ISession example, it hides all the co-ordination with the identity map, cache, database, persisters, change tracking, etc. This leaves the user with a single, simpler interface that matches their intent, get me an object, run this query, commit the transaction.

I agree that the problem with this post is the example, not the pattern. The example provides no value, that is true, but the pattern itself is very useful. Let's not throw the baby out with the bath water.

Come to think of it, most of the posts in this series end on a negative note about what not to do. The patterns have withstood the test of time for a reason, they work. The problem is most devs, myself included, are not properly informed/trained in how to apply them.

I think that's exactly the usefulness of these posts - the developers should not apply a pattern unless they truly understand when and why it's useful, not just because they heard from other people that it's cool to use patterns..

I agree with Zdeslav 100%. Don't really see the example as a Facade. Facades are useful if you need to interact with a large class library/API in a very limited and specific way. It's very useful and I don't see that I would give it up any time soon.

In my opinion, anything that hides complexity implements the Facade pattern. That means every class/method implements this pattern. Def: A facade is an object that provides a simplified interface to a larger body of code.

I'm guilty of implementing a façade to System.IO in FluentPath. It adds nothing in terms of functionality and is an additional abstraction layer, yes, but I would argue that beyond being a million times nicer to work with than the mess of static APIs that System.IO is, it also helps for testability because it's possible to mock the file system whereas the original API makes that very hard.

I think a good example of a facade is JsonConvert class in Json.NET. It hides away having to create a serializer and readers/writers and gives people 1 line methods to serialize and deserialize JSON strings, which is really what most people want.

One place where I felt a Facade came in useful was writing code against a IO card which accepted commands at a fairly low level (e.g. read/write bytes X to/from port Y). The facade allowed me to expose behaviour like EnableFoo(), DisableBar(), ReadBaz(). This is just the first example of where the usefulness of this pattern was obvious.