The answer to your question, Eric, is that neither pattern is in
commons-chain, as you suggest. The commons chain is a Chain of
Responsibility pattern. My concern was with the Struts classes, and I
think that I have received an answer on my inquiry, viz. that a
refactoring to a Strategy pattern in the Struts chain would probably
be a good idea, and that the present Template Method pattern used
there with commons-chain is more a matter of inertia than considered
choice at this point.
I have no idea why Craig would say that the RequestProcessor is
somehow related to the Template Method pattern. It just isn't.
As Ted said and whch makes sense to me, in another thread that is
currently winding down:
<SNIP>
"Just to clarify the process ...
We never "decided" to use Template versus Strategy. Craig started
coding up one way of doing the request processor as a chain, then Joe
and others picked up the ball and ran with it.
Absolutely ALL of the routihne development conversations happen here.
The one and only time a "decision" is every really made is when
somebody commits code.
So far, the code people have written for Struts Chain could be cast as
using the "Template" pattern. If someone coughs up another working
implementation that would be easier to extend and support, I'm sure
we'd be eager to consider the donation.
BUT -- we don't decide in advance that we are going to do this or that
and then shut the door. People do it, and THEN we decide if we're
going to keep it.
Right now, the real advantage to the Template is that we already got
one. The only way that will change is if someone takes the initiative
and writes another working implementation."
</SNIP>
If you look at the actual code in the Struts v1.3 chain that is
supplanting RequestProcessor, you will see that the chain that is
supplanting that class are commons-chain commands that are written
with the Template Method pattern in the classes which implement
Command. That is the issue. They were running into problems with the
code and I wondered why they did not use classes which implemented
Command and used the Strategy pattern. I think that most people would
agree that there really is very little to recommend in the Template
Method pattern.
I discussed this with Joe in another thread as well. There, to quote
myself following the standard mantra in this area:
<SNIP>
The only real advantage to the Template Method pattern is that you can
make the template, abstarct class work simply by instantiating a
concrete subclass. You don't have to manage a relationship between
the class and business objects. First, this advantage is irrelevant
when running in an IoC container, so down the road the Template Method
pattern hopefully would not have a single advantage. Second, the
advantages of the Strategy pattern are considerable in contrast:
a. The strategy can be changed at runtime. Concrete inheritance is
defined statically and is inflexible. Composition is better.
b. Multiple strategies might be necessary. With concrete inheritance
all of them are linked. The strategy approach allows them to be mixed
in any combination. I think the Struts developers with v1.3 are
running into these difficulties and it is creating a real problem, if
I am not mistaken.
c. The same strategy interface can be used in multiple classes. A
single use of an expensive instance of a class can be used for
multiple objects' state.
d. You can test it with mock objects.
</SNIP>
Anyway, you are definitely right that the Template Method pattern is
not used in commons-chain.
I have no idea why Craig thinks that the Chain of Responsibility
pattern in commons-chain is somehow on any level (pragmattic,
pedantic, or otherwise) an instance of the Strategy pattern. It
clearly is not, since the Strategy pattern essentially utilizes
composition.
The Strategy pattern is useful for providing multiple variations on an
algorithm or behavior. This makes it particularly useful if you want
to make the internals of a framework amenable to custom classes being
built by users. The Strategy pattern makes this possible by
encapulating the behavior into separate classes that provide a
consistent way of accessing the variants on the behaviors. This
division into classes means that the classes that use them need to
know nothing about their implementation.
The Chain of Responsibility allows you to send a command to another
object without specifying the receiver.
What happens in one of these commands is where the Strategy pattern
becomes useful. You can create a chain with the commands using a
Strategy pattern and have the use of both worlds. In my opinion, the
use of the CoR is relatively unimportant in breaking down the
RequestProcessor logic. CoR is only important because of the
weaknesses in Template Method which Bill Biggelow discusses in a
recent article. If you used Strategy instead of Template Method, you
could use CoR but would not need to. Vic has discussed why he likes
using CoR apart from the weaknesses of Template Method and I have to
admit he is fairly convincing on that score. Refactoring to Strategy
would still, however, I think, be much better. Much (!) better!
On Sun, 06 Mar 2005 20:04:04 -0500, Erik Weber <[EMAIL PROTECTED]> wrote:
> I guess here's a way I can restate my question.
>
> I'm with you on choosing composition rather than inheritance when it's
> possible and sensible. But it's not always obvious where and how
> inheritance can be replaced by composition. I find it to be a
> challenging part of programming. So that's why I became interested.
> Also, sometimes in prototyping, you design a good API, you use
> inheritance underneath to get something working, and then you hope to
> refactor later.
>
> If (a literal) Template is this:
>
> public abstract class Chain {
>
> public final void execute() {
> doA();
> doB();
> doC();
> }
>
> public abstract void doA();
> public abstract void doB();
> public abstract void doC();
>
> }
>
> Then I'm having trouble seeing where this exists in Commons Chain
> (sorry, I haven't exactly gone through a lot of code). What I do see is
> a sort of "higher" template -- A chain will be executed but the commands
> are virtual, as in a literal Template. Perhaps the answer is in your
> words when you say "implementations" of Commons Chain (rather than the
> libraries themselves). If that's true I would appreciate it if you could
> point out a clear example.
>
> I think Bill's article overall is good because it explains pretty
> clearly how Commons Chain works, however, why does he bring up Template
> in the first place? That's where I get lost . . . Is he saying that
> Commons Chain offers a better way to solve the problem that a literal
> Template solves by using a sort of higher abstraction of a template (one
> that leaves class inheritance behind)? If that's true then it's possible
> that the detriments of Template no longer apply, and that Strategy might
> not be any better (or even as good). If that's not true, however, and
> the code I posted above exists (almost) literally in Commons Chain (or
> in typical implementations), then it's a healthy question (as always) to
> ask, why not composition rather than inheritance, if possible?
>
> I guess I need to spend more time with Commons Chain and maybe it will
> become clearer.
>
> Erik
>
> Dakota Jack wrote:
>
> >I think I stated the problem badly, Eric. If you look at the
> >implementations of commons-chain you will see the implementations tend
> >to use Template Method. The chain is used to solve the rather
> >troublesome problems with that pattern, and yet the people who go to
> >all the trouble to change to chain do so while staying with the
> >Template Method. The move to chain, in my opinion, allows us to get
> >free of the Template Method and to use Strategy instead. Bill's
> >article is about the use of Template Method with chain and the propsed
> >changes in Struts v1.3 use Template Method with chain. Chain solves
> >many of the problems with Template Method, but my suggestion is that,
> >if you are going to implement chain and make that big change in v1.3
> >anyway, why not switch to Strategy will doing so and abandon all those
> >problems. (I am, perhaps, overstating the problems with Template
> >Method a bit,, but this seems to be okay given that there is a better
> >option available with Strategy. I think people generally agree that
> >Strategy is a better pattern that Template Method to do the same
> >thing.)
> >
> >
> >On Sun, 06 Mar 2005 18:22:44 -0500, Erik Weber <[EMAIL PROTECTED]> wrote:
> >
> >
> >>I think it's probably usually good to question Template when the
> >>realization of it comes via class inheritance.
> >>
> >>However, I'm confused. I read Bill's article (first pass anyway -- and
> >>I'm new to Commons Chain), and I'm still not seeing where exactly
> >>Template is implemented in Commons Chain. He introduces Template and
> >>then seems to say that while Template is still used, its detriments are
> >>mitigated. But I need help understanding exactly where it is used in the
> >>first place. (I'm not making the connection between the first code chunk
> >>and the following ones.) Only then will I be able to assess the question
> >>of whether Strategy would be better (or would even solve the same problem).
> >>
> >>Here's a diagram of Template:
> >>
> >>http://www.dofactory.com/Patterns/PatternTemplate.aspx
> >>
> >>And here's a diagram of Strategy:
> >>
> >>http://www.dofactory.com/Patterns/PatternStrategy.aspx
> >>
> >>Could you plug the Commons Chain classes (existing or proposed) into an
> >>illustration (verbal will do) for me so I can better understand the debate?
> >>
> >>Thanks,
> >>Erik
> >>
> >>
> >>Dakota Jack wrote:
> >>
> >>
> >>
> >>>I inquired why the Template Method pattern is being used with Commons
> >>>Chain instead of Strategy, but never got an answer. Given that the
> >>>choice seems so problematic, that surprised me. Is that (no response)
> >>>because there is no answer, or because it is a closed shop of ideas in
> >>>open source, or because there is no time to consider such a stupid
> >>>idea, etc.?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
