You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Bill Siggelkow <bi...@bellsouth.net> on 2005/02/10 04:12:18 UTC
Chain: Is it really CoR or Template Method? or both?
The documentation and API of commons-chain frequently refers to the
chain of responsibility pattern; however, my first impression was that
its more like the Template Method. I would be interested in how others
perceive this ... in either respect, I'm inclined to consider chain to
be a melding of the two (plus the Command and Composite patterns thrown
in). Certainly the "handling" aspect of Commons-chain commands stem from
the CoR pattern. However, the notion of defining a sequential set of
commands, using either the XML config file or the API, feels like
Template Method.
I realize that this is a somewhat academic discussion; however,
understanding the common patterns underlying chain help us frame its
applicability to the general public. I'm also writing an article on
commons-chain and have been puzzling over this issue.
-Bill Siggelkow
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Chain: Is it really CoR or Template Method? or both?
Posted by Bill Siggelkow <bi...@bellsouth.net>.
I agree, Craig ... unlike CoR, the Template Method does not explicitly
dictate how the algorithm terminates. (Of course, one could contend that
traditional Java exceptions could serve this purpose).
I think it was Martin Fowler who said that design patterns should be
simply taken as standalone solutions; rather its the combination of
these patterns that are really interesting.
This is how I view chain ... its a mechanism for implementing a chain of
responsibility where the chain can be defined dynamically. I also see it
as a great alternative for replacement of hard-coded algorithms
(step-by-step processes) specified in a class using Template Method
(e.g. RequestProcessor). Of course, the fly in the ointment in such
generic frameworks is the reliance on the Context (what I like to call a
YAGHT-yet another glorified hash table). In other words, while its now
possible to vary the algorithm at run-time (or at start-up time via XML
configuration), links in the chain are dependent on the presence of
certain objects in the Context.
I will say that I think the reflective capability of the ContextBase
class mitigates this problem; in other words, you can implement
compile-time checks using a ContextBase subclass with traditional
JavaBean properties, yet still allow generic Commands that can access
properties through dynamically through a map.
-Bill Siggelkow
Craig McClanahan wrote:
> The key reason I think of Commons Chain as implementing CoR is that
> any given command in the chain can say "that's it; this 'request' has
> been handled; do not go any further," which is part of the classic
> description of this pattern. That happens to not be the way that
> things like the request processor deconstruction in Struts 1.3.x are
> using it for, but this usage is still viable if you need the "keep
> delegating until you find someone who will deal with this problem"
> approach.
>
> Craig
>
>
> On Wed, 09 Feb 2005 22:12:18 -0500, Bill Siggelkow
> <bi...@bellsouth.net> wrote:
>
>>The documentation and API of commons-chain frequently refers to the
>>chain of responsibility pattern; however, my first impression was that
>>its more like the Template Method. I would be interested in how others
>>perceive this ... in either respect, I'm inclined to consider chain to
>>be a melding of the two (plus the Command and Composite patterns thrown
>>in). Certainly the "handling" aspect of Commons-chain commands stem from
>>the CoR pattern. However, the notion of defining a sequential set of
>>commands, using either the XML config file or the API, feels like
>>Template Method.
>>
>>I realize that this is a somewhat academic discussion; however,
>>understanding the common patterns underlying chain help us frame its
>>applicability to the general public. I'm also writing an article on
>>commons-chain and have been puzzling over this issue.
>>
>>-Bill Siggelkow
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Chain: Is it really CoR or Template Method? or both?
Posted by Craig McClanahan <cr...@gmail.com>.
The key reason I think of Commons Chain as implementing CoR is that
any given command in the chain can say "that's it; this 'request' has
been handled; do not go any further," which is part of the classic
description of this pattern. That happens to not be the way that
things like the request processor deconstruction in Struts 1.3.x are
using it for, but this usage is still viable if you need the "keep
delegating until you find someone who will deal with this problem"
approach.
Craig
On Wed, 09 Feb 2005 22:12:18 -0500, Bill Siggelkow
<bi...@bellsouth.net> wrote:
> The documentation and API of commons-chain frequently refers to the
> chain of responsibility pattern; however, my first impression was that
> its more like the Template Method. I would be interested in how others
> perceive this ... in either respect, I'm inclined to consider chain to
> be a melding of the two (plus the Command and Composite patterns thrown
> in). Certainly the "handling" aspect of Commons-chain commands stem from
> the CoR pattern. However, the notion of defining a sequential set of
> commands, using either the XML config file or the API, feels like
> Template Method.
>
> I realize that this is a somewhat academic discussion; however,
> understanding the common patterns underlying chain help us frame its
> applicability to the general public. I'm also writing an article on
> commons-chain and have been puzzling over this issue.
>
> -Bill Siggelkow
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org