﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Nick commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>I have seen code just like this too many times for it to be a sick joke.</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment26</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment26</guid><pubDate>Tue, 13 Nov 2012 19:39:22 GMT</pubDate></item><item><title>@lroal commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>@dmitry: Just define the right sub system (set of classes) and any abstraction will fit the pattern. It could be your own classes, an external lib or a mix.</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment25</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment25</guid><pubDate>Tue, 13 Nov 2012 16:28:47 GMT</pubDate></item><item><title>Dmitry commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>@lroal,

You are describing general abstractions. Abstraction is one of the OO principles meaning objects were invented to abstract code.

All GOF patterns are created for specific scenarios. Facade pattern is designed to abstract a low level API that is specific to your application, not HTML, TCP/IP or operating system calls.

See Oren's todays post.</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment24</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment24</guid><pubDate>Mon, 12 Nov 2012 19:30:48 GMT</pubDate></item><item><title>Dan Turner commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>@Chris Chilvers absolutely 110% spot on!  I couldn't have said it better myself.</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment23</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment23</guid><pubDate>Mon, 12 Nov 2012 01:22:59 GMT</pubDate></item><item><title>@lroal commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>@bala: yes they are</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment22</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment22</guid><pubDate>Sun, 11 Nov 2012 19:12:38 GMT</pubDate></item><item><title>Joshka commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>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.</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment21</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment21</guid><pubDate>Sun, 11 Nov 2012 14:18:05 GMT</pubDate></item><item><title>bala commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>DOes it mean all abstractions are infact Facade instances?</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment20</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment20</guid><pubDate>Sun, 11 Nov 2012 08:06:16 GMT</pubDate></item><item><title>@lroal commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>Dmitry: NewGuid() is both facade and factory method.
You say it does not hide low level api? Well..I strongly disagree.

Yes, most methods hide complexity and therefore implements facade pattern. All patterns are are subpatterns of Facade.  Facade is the most powerful pattern - and most boring - which is awesome.</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment19</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment19</guid><pubDate>Sat, 10 Nov 2012 14:36:15 GMT</pubDate></item><item><title>Dmitry commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>Guid.NewGuid() is a factory method (not the GOF factory pattern). It is responsible for creating Guids, not hiding a low-level API. Going by that logic, most methods hide some code complexity.

WebClient is an example of a facade over WebRequest/WebResponse.</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment18</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment18</guid><pubDate>Sat, 10 Nov 2012 02:56:45 GMT</pubDate></item><item><title>@lroal commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>What about Guid.NewGuid() ?

In fact, any method or object is a great example. </description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment17</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment17</guid><pubDate>Fri, 09 Nov 2012 21:08:08 GMT</pubDate></item><item><title>James Newton-King commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>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.</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment16</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment16</guid><pubDate>Fri, 09 Nov 2012 20:59:42 GMT</pubDate></item><item><title>Falko Janak commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>In my eyes jQuery provides great facades to support most common browsers. I don't think the facade pattern is evil. Abuse is evil ;)</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment15</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment15</guid><pubDate>Fri, 09 Nov 2012 20:18:04 GMT</pubDate></item><item><title>Rafal commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>Web services or REST-style interfaces are often implemented as facades over underlying data types and request-scoped session management. Quite common and also correct.</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment14</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment14</guid><pubDate>Fri, 09 Nov 2012 18:53:21 GMT</pubDate></item><item><title>Bertrand Le Roy commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>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.</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment13</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment13</guid><pubDate>Fri, 09 Nov 2012 18:39:30 GMT</pubDate></item><item><title>Ale Miralles commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>Agree with Zdeslav, WebRequest class is a way better example to show off the pattern</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment12</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment12</guid><pubDate>Fri, 09 Nov 2012 18:34:45 GMT</pubDate></item><item><title>@lroal commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>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. </description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment11</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment11</guid><pubDate>Fri, 09 Nov 2012 17:37:32 GMT</pubDate></item><item><title>J.P. Hamilton commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>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. </description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment10</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment10</guid><pubDate>Fri, 09 Nov 2012 16:48:05 GMT</pubDate></item><item><title>Tudor commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>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.. </description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment9</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment9</guid><pubDate>Fri, 09 Nov 2012 14:43:48 GMT</pubDate></item><item><title>Jason Meckley commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>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.</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment8</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment8</guid><pubDate>Fri, 09 Nov 2012 13:20:37 GMT</pubDate></item><item><title>Chris Chilvers commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>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.</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment7</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment7</guid><pubDate>Fri, 09 Nov 2012 13:06:42 GMT</pubDate></item><item><title>jgauffin commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>TcpClient/TcpListener are facades making it easier to work with sockets. imho they are good examples of facades. 

A facade doesn't have to hide complexity of several classes.

Another example is nhibernate ;) It hides the ADO.NET/DB plumbing</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment6</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment6</guid><pubDate>Fri, 09 Nov 2012 12:37:20 GMT</pubDate></item><item><title>jgauffin commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>The View Model is not a Facade at all. It's an adapter. It adapts the model information into something that a view can use.

For instance a list of users are converted into a SelectListemItem array</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment5</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment5</guid><pubDate>Fri, 09 Nov 2012 12:34:05 GMT</pubDate></item><item><title>Apostol commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>@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.
</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment4</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment4</guid><pubDate>Fri, 09 Nov 2012 12:14:31 GMT</pubDate></item><item><title>Charles Flatt commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>Would you consider a View Model from the .Net MVC world a facade? It seems to fit the pattern exactly.</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment3</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment3</guid><pubDate>Fri, 09 Nov 2012 11:46:30 GMT</pubDate></item><item><title>Zdeslav commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>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</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment2</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment2</guid><pubDate>Fri, 09 Nov 2012 11:32:30 GMT</pubDate></item><item><title>Frank Quednau commented on Design patterns in the test of time: Fa&amp;ccedil;ade</title><description>One could argue whether High-Level APIs to complex object relationships aren't Facades, but I think the common term is Object Builder...</description><link>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment1</link><guid>http://ayende.com/159681/design-patterns-in-the-test-of-time-facade#comment1</guid><pubDate>Fri, 09 Nov 2012 10:34:50 GMT</pubDate></item></channel></rss>