{{ !articles[0].partner.isSponsoringArticle ? "Platinum" : "Portal" }} Partner

What the Façade Pattern Is and What it Ain’t

I decided to respond to some of the comments about the design patterns series in my blog in a full blown post, because they are quite important.

  • View Model is not a façade. It doesn’t allow any operation, and it doesn’t simplify things. It merely give you an easy access to aggregate information.
  • No, every class is not a Façade. I don’t care if “it provides simplified interface to a larger body of code”. If everything is a façade, then façade is meaningless.
  • No, Web Request is no a façade. Sure, it hides a lot of details about TCP, but that isn’t its point. Web Request implements HTTP spec, and that isn’t a façade at all.
  • Web Client / Tcp Client / Tcp Listener are facades – they drastically simplify how to work with sockets. Good facades, too, because when you need to do more, they don’t block you.
  • NHibernate ain’t a façade – it hides ADO.NET, sure, but it also does a lot more then just that.

The whole point of this series of posts was not to talk about patterns. If you want to do that, go ahead and read the books. My attempt is to go and talk about how the patterns are actually used. In practice, in real code.

Sure, in the real world, patterns aren’t used as per their text book definition. That doesn’t mean that we should look at the text book definition. That means that we need to look at how they are actually used! I am not writing a series of posts talking about the problems in the patterns, and that is important. I am writing about the problems in how people use them.

Published at DZone with permission of {{ articles[0].authors[0].realName }}, DZone MVB. (source)

Opinions expressed by DZone contributors are their own.

{{ tag }}, {{tag}},

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

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks