Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of craigmcc@gmail.com designates
 64.233.170.201 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=mf+j1++ikutcU8JaPYkhVeJAZJCCHHD6HCI6wC3uIRJFrCTuGb1sagFMV9vNlfxpHtMU3K9ziLRCinfsuvE55f/X7QUVJUkRdxR0x6IelYE14r92Qku/4J2QLP6PODHFABMqKOv1AX1yLyrMbesMRSFgt45ZFdRRqrS+8imW8T4
Message-ID: <f8b39ace04101910134ccf3d6d@mail.gmail.com>
Date: Tue, 19 Oct 2004 10:13:55 -0700
From: Craig McClanahan <craigmcc@gmail.com>
Reply-To: Craig McClanahan <craigmcc@gmail.com>
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: [chain] Is anybody out there using chain in a production system?
In-Reply-To: <417528E3.60101@schof.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <41751DD5.2030607@indra.es> <417528E3.60101@schof.com>

On Tue, 19 Oct 2004 10:46:59 -0400, Sean Schofield
<sean_schofield@schof.com> 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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org