On Mon, 06 Aug 2012 10:24:10 +0100, lipska the kat wrote:
> er, the point I was trying to make is that when you say 'interface' it
> could mean so many things. If you say 'facade' everyone knows exactly
> what you are talking about. And that is EXACTLY the point.
The whole point of design patterns is to avoid getting stuck in
incidental implementation details of a particular library or class and
look for higher-level design patterns.
The same applies to facade -- it's just a special case of the interface
pattern. Why get stuck in incidental implementation details of the
particular *kind* of interface layer you need?
Obviously the person writing the interface/facade/adaptor/whatever needs
to understand the implementation details. But the people using the
interface don't.
Why waste brain CPUs trying to decide whether a particular interface is a
facade, an adaptor, a bridge, a proxy, ... ? Especially since in real-
life code, any such interface is going to include elements of all of the
above. Take this example from Wikipedia's article on Facade pattern:
========= ========
Pattern Intent
========= ========
Adapter Converts one interface to another so that it matches
what the client is expecting
Decorator Adds responsibility to the interface without altering it
Facade Provides a simplified interface
========= ========
It's rare that the intent is as pure as that. Normally it will be:
"Simplify the interface, oh and also change the API of these three
methods to match this other library, and add a couple of helper methods,
and while you're at it, this method has a bug that upstream refuses to
patch, do something about that."
So is that a facade or an adaptor, or something else?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
