Fundamental Construction Metaphors
Fundamental Construction MetaphorsAt one point, my ideal program was what I called ObjectSoup?. That is, true beauty was to be found in a sort of background broth (singletons supplying useful information about the machine and resources) along with thousands of truly small and almost-stateless objects which communicated solely by the observer pattern (along with the occasional callback from a notification). It's an interesting way to build things and I've built large-scale, shipping code that works this way. But it's got problems too.
These days, I've migrated to something I call TinyClientsTinyServers. The idea is that you can break a task down into three main things: the goals to accomplish, the assumptions being made, and the primitive actions that are taken. This then leads to the definition of a tiny server
The interesting part is this: If you start with a BigBallOfMud and you want to decouple everything, you will probably adopt one of the above two approaches. And whether or not exceptions are a useful tool is entirely dependent on which approach you use.
Is the facade/delegatee split a policy/mechanism split, as described by MechanismRichPolicyFree? Or are you arguing that every object offers primitives to its clients and imposes policy on the objects attached to its instance variables? -- DaveHarris
Hmmm. This was a bit unclear. Basically facade/delegatee is delegating both. The facades provide a nice semantic API. Then, the underlying policy and mechanism are both delgated out via the strategy pattern.
But that's secondary to the idea I was trying to express. Namely, I find that my first cut at a set of objects is fairly densely intertwined (the naive view on each object in the first cut is that they know a lot about many other objects). Then, a major task is to build the infrastructure in such a way that everything winds up decoupled as much as possible. The two ways I've had success doing this are through massive use of the observer pattern and through the strategic insertion of facades which define a tiny server to the rest of the application.
And the point is that explicitly adopting the server metaphor leads to a natural notion of exceptions and policies for handling/interpreting exceptions. But large scale use of observer (the other decoupling strategy) doesn't seem nearly so well fitted to exceptions. you get other benefits when you do what I, in a previous pattern, called ExtendedObserver, and it's wicked cool, but you lose the nice fit with exception handling.
Re: MultiCaster If I understand it correctly, then it's much more similar to the observer based approach. In fact, if I understand it correctly, MultiCaster is very similar to the ExtendedObserver pattern I put on RalphJohnson's stories site lo these many years ago (with the exception that we added in flow-control mechanisms and prioritization to the MultiCaster object).
I'd be interested in seeing if I read MultiCaster right.
That implies that several facades can share the same server; is that right? Is the facade doing much more than reducing the surface area of its server, from the POV of its client? Or is it adding value in some other way?
Specifically, instead of the facades could you use multiple interfaces (in Java) and/or selective export (in Eiffel)? These provide ways to expose a subset of an API to specific (classes of) clients without involving a new object or delegation. -- DaveHarris
EditText of this page
(last edited July 1, 2003)
or FindPage with title or text search