On Tue, 19 Oct 2004 10:46:59 -0400, Sean Schofield <[EMAIL PROTECTED]> wrote:
> [snip] > I think the main drawback to the chain of responsibility (COR) pattern > is the lack of type safety (and transparency) that pops up in a typical > implementation. As you mentioned, commons-chain requires everything to > be "jammed" into a context. > This is indeed a key consideration ... the price of making the method signature of a Command be generic is that the state of the computation is encapsulated in a "context". However, you do have an architectural choice in how you actually implement this, thanks to the fact that the base implementation of Context provided in [chain] supplies "attribute-property transparency": * Command implementations may treat the Context argument as an opaque Map, calling get() and put() operations with casts in the usual way. * The application architecture may supply subclasses of Context that include typesafe properties for application specific "well known" properties, but allows the use of generic accessors for everything else. The Command would have to cast the Context instance, but from there on gains type safety for the well known things. Indeed, [chain] supplies examples of the latter technique in the org.apache.commons.chain.web package, where predefined slots for things specific to using [chain] in a web environment are provided. My sense is that, no matter how generic we try to make our commands, we're always building in *some* level of assumptions about the contents of the Context (if nothing else, you have to agree on keys, for example). Therefore, I will tend to write application specific context classes for the most commonly shared attributes. It's also possible to think about Context items being used in more than one application specific context -- for that, you can define the typesafe properties contract for each application domain in an interface that extends Context, and then build an implementation that implements all of the interfaces. It's not perfect, but to me this approach seems like a reasonable tradeoff for the flexibility that [chain] gives you in composing the processing that will actually happen. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
