Re: Facade


Padu wrote:
Hi everybody,

I've been thinking about the facade pattern lately, and it seems to me that
one very good use for it is to implement one facade in every subsystem, like
a summary.
In a case like this, every subsystem (a namespace for example) would have a
"denormalized" facade that would present the most commonly used services
from that namespace, simplifying things for 90% of clients in other
namespaces.

What do you think of it?

Cheers

Padu

A couple of points.

Unfortunately my girlfriend has my copy of Design Patterns at the
moment (I'm beginning to suspect that a hostage situation is brewing,
but that's another story), so I can't quote scripture, but it's
important to note that a Facade is not just one interface.

Ok, I'm using the term, "Interface," in the Java-sense; perhaps more
general to say, "Abstract class." The Facade pattern recommends that
the Facade can be a collection of abstract classes providing access to
the name space in question. I only mention this because a couple of the
mails in the thread seemed to suggest otherwise, certainly in terms of
the, "Narrowness," of the Facade. I may have interpretted wrongly.

Secondly, I don't know what you mean by a, "Denormalized," Facade -
care to clarify?

On the whole, I think Facading your name spaces is an excellent idea,
and can yield even more value if you then store the Facade (i.e.,
collection of abstract classes) somewhere removed from the name spaces
to which they give access, thus separating your Facades the structure
of your hierarchical name space (and empowering, "Program to an
interface repository, not an implementation repository").

Simple example given here:
http://www.edmundkirwan.com/servlet/fractal/frac-page70.html

The eminent Unlce Bob mentioned, "Most subsystems are not
"facadeable", and you should not expend effort into making them fit
into a facade." This worries me a little, so I hope Bob's, "Subsystem,"
is not the, "Name space," I mention, as a name space should contain
logically related behaviours that you wish to encapsulate away from the
rest of the system: almost by definition, a name space should be
Facadable, as otherwise there's too much disparate behaviour lumped
together.

..ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition

.

Relevant Pages

  • Re: Why instantiate a class, all of whose methods, properties, and events are static?
    ... Jon Skeet wrote: ... denomination is "facade". ... Facade pattern and whether or not methods are static are not related. ... An example would be if you have a fairly common operation to perform that requires some complex coordination among other objects. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why instantiate a class, all of whose methods, properties, and events are static?
    ... The Facade pattern is a way to create a simple interface on top of a complex system. ... An example would be if you have a fairly common operation to perform that requires some complex coordination among other objects. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why instantiate a class, all of whose methods, properties, and events are static?
    ... I'm learning the .net Bloomberg api, and it's main class has all of its ... denomination is "facade". ... That's not my understanding of the facade pattern. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Facade
    ... I've been thinking about the facade pattern lately, and it seems to me that one very good use for it is to implement one facade in every subsystem, like a summary. ... In a case like this, every subsystem (a namespace for example) would have a "denormalized" facade that would present the most commonly used services from that namespace, simplifying things for 90% of clients in other namespaces. ... You use a facade only when there is a simple interface to the whole subsystem, and a strong reason to hide some elements of the subsystem from the rest of the application. ...
    (comp.object)
  • Facade
    ... one very good use for it is to implement one facade in every subsystem, ... from that namespace, simplifying things for 90% of clients in other ... Padu ...
    (comp.object)