You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Dakota Jack <da...@gmail.com> on 2005/03/06 05:34:06 UTC
Why Template Method instead of Strategy in Commons Chain?
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.?
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Craig McClanahan <cr...@gmail.com>.
On Sat, 5 Mar 2005 20:34:06 -0800, Dakota Jack <da...@gmail.com> wrote:
> I inquired why the Template Method pattern is being used with Commons
> Chain instead of Strategy, but never got an answer.
Back in town (for at least one day), and snipping off the flamebait
:-), it's worth philosophizing for just a coule of minutes.
Choosing between CoR, Strategy, and Template patterns is, at least
partly, a choice of the fine-grainedness you want for your abstraction
that is the basis for reusability. In Struts 1.1/1.2, for example,
one could consider the monolithic RequestProcessor class to be an
example of the Template approach (although it mashes the abstract base
class and default concrete implementation into a single class that you
can override and specialize). A strategy pattern approach to that
would have been to define RequestProcessor as an interface, perhaps
with a separate default implemetation, but you're at pretty much the
same point either way -- the set of steps (in the case of Struts, the
identity and ordering of the processXxx methods) is pretty much fixed,
and you've got a very coarse-grained replacement abstraction.
CoR as a pattern goes all the way to the other extreme, and tries to
make the unit of replacement as fine grained as possible. Not only
are the individual steps small and relatively independent (the linkage
between them is knowing the keys in the context that they use to pass
information back and forth), but you are completely free to change the
order of the steps, insert new steps, or omit steps you don't need.
If you are disciplined about how you construct your steps, this can
give you a pretty significant degree of reuse. For example, assume
you're building a CRUD type application by doing direct SQL through a
JDBC connection (whether that's a good idea or not is totally
immaterial to the illustration -- just pay attention to the philosophy
here). One might construct individual steps like this (for an update
transaction):
Initial state - primary key of the row you're going to update is in
the context under a well-known key. The updated fields are available
in other places (as a DTO, as a bunch of individual properties, or
whatever) that are also well known.
(a) Acquire a JDBC connection somehow, and store it in the context
(b) Based on the primary key (from the context), retrieve the current
data for the master row you're going to update
(c) Check the timestamp in the retrieved data to make sure nobody
else has updated the row first, while you were away
(d) Perform the appropriate updates
(e) Commit the transaction
(f) Release the JDBC connection back to where it came from.
With fine grainedness like this, you can easily reuse *portions* of
this business logic, with several variations on the theme:
* Steps (a) and (f) are reusable for any sort of transaction
that talks to this database. They are mutually interdependent,
which leads to a design choice discussed further below.
* You can have an implementation of (a) and (f) that grabs
something out of a JNDI-accessed data source for use in a
webapp, and a separate implementation that just reuses the
same Connection instance for a batch application, without
the rest of the chain knowing anything.
* Step (b) can be reused for any transaction that requires
retrieving the existing information from this particular table.
It doesn't care what happens after it's done its work -- that
is for the rest of the chain to determine.
* Step (c) is totally optional if you're working in an environment
where you don't have to worry about intervening updates, so
you could leave it out of a chain executed in that area.
* Step (d) is normally specific to the particular chain you are
executing, but it might still be reusable if you have more than
one business transaction that, perhaps, updates different
subsets of all the columns in this row.
* Making step (e) separate lets you construct chains that
update an arbitrary number of different rows in the same
SQL transaction, without the individual updates having to
be aware of any of the others.
In a large administrative app, you might construct hundreds of chains
like this (or define subchains that are executed via something like
LookupCommand to reduce the tedium of configuration) and have a large
degree of reuse over the set of individual command implementations.
And those same commands can be reused again in a batch app, or on the
back end of a web service, or at the back end of a request from client
JavaScript using XmlHttpRequest, or from anything else. As an extra
added benefit, writing unit tests for such fine grained things is very
easy ... just set up a context with the required incoming information,
execute the command, and check the results for the required
postconditions.
Think of the individual steps as LEGOs, plastic building blocks which
can snap together in all sorts of combinations, but only at certain
well-defined interface points (i.e. with some way to know what context
keys are used to pass in the input state and pass out the output
state).
The Template Method approach (and Strategy, for that matter, although
to a lesser degree) make more sense (at least to me) when you have a
set of interrelated operations that can be performed on some thing,
*and* the set of operations is the same for all potential
implementations of sets of those operations. You also have to deal
with the impacts of changes to the interfaces to these sets (for
example, adding a method to a Java interface is likely to break all
existing implementations, unless they all happen to subclass a common
base class where you can provide default behavior.
That all being said, I'm not ever going to use things like
org.apache.commons.chain.generic.DispatchCommand or
org.apache.commons.chain.DispatchLookupCommand myself -- mixing
metaphors :-) like this gives up some of the reusability I'm after
when I choose a CoR pattern in the first place. But I could see why
someone might want to do this, in the example above, to combine (a)
and (f) into a single source class because there is a 1:1 relationship
between the implementations of each step (for any possible overall
approach to acquiring connections).
At a pragmatic level, that's the sort of relationship I would document
in instructions to the architects assembling chains, rather than
embedding in the structure of the code. Others may see that
differently, which is why frameworks sometimes have to accomodate
different strokes for different folks.
Craig
PS: Pedantically, one could argue that CoR as implemented in [chain]
is one single implementation of the Strategy pattern that can be
reused by everyone -- in the pointed-at diagram of the pattern,
replace the word "Strategy" with "Command" and "AlgorithmInterface"
with "execute" :-). But that's a discussion that doesn't lead
anywhere useful, so I won't be bothered to discuss it again. As the
Javadocs tell you, [chain] was specifically intended to be an
implementatin of the Chain of Responsibility pattern as described in
the GoF book.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [chain] Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Dakota Jack <da...@gmail.com>.
Thanks for the note on the "component name in brackets", Phil. I have
not posted much to commons and forgot. Sorry!
There is a clear reason to cross post. I have suggested to the people
in Struts, who are working on an implementation of commons chain to
build a CoR for the RequestProcessor in Struts v1.3 and beyond, that
they should be using Strategy with commons chain rather than Template
Method. I figured that the topic clearly was Struts related but that
people in commons chain might have a better idea on the vagarities,
etc. on that than the Struts people would have.
On the user versus development post, my experience is that when
discussing these fundamental things, whichever way I post, someone
will tell me to do the opposite. I can point out many, many examples
of that. I consistently get decorum answers as opposed to answers on
the substance. In this case, too, the point is _largely_ user related
in the commons chain context.
Can you give me any idea why one would prefer to use commons chain
with Template Method rather that Strategy? This seems to me to be
both a user and developer question for commons chain and clearly
relevant to Struts development and users who care about such things.
(I have been told that development in Struts is only for actual work
on given code and that _general_ discussions like this should go on
users. So, there you go?)
If you could response on the merits of this fairly simple but
fundamental issue, I would be more than happy. Sometimes the
temperature on Apache lists for these sorts of discussion feel like
the descent into The Inferno by Dante, i.e. colder than hell! Here
are the alternatives. I think that the Strategy pattern is so
superior and so well know to be superior that the use of the Template
Method pattern just floors me. I am completely open to being wrong on
this and would just like to have a discussion on it. That should be
quick and easy thing to do. I have found it, so far, to be
impossible.
Struts proposed v1.3 does the following in using commons chain for the
RequestProcessor:
STRUTS USE OF TEMPLATE METHOD IN PROPOSED v1.3
public abstract class AbstractPopulateActionForm implements Command {
public boolean execute(Context context) throws Exception {
// do stuff
reset(actionCtx, actionConfig, actionForm);
populate(actionCtx, actionConfig, actionForm);
handleCancel(actionCtx, actionConfig, actionForm);
return (false);
}
protected abstract void reset(ActionContext context,
ActionConfig actionConfig,
ActionForm actionForm);
protected abstract void populate(ActionContext context,
ActionConfig actionConfig,
ActionForm
actionForm) throws Exception;
protected String trimParameterName(ActionConfig actionConfig, String name) {
// do stuff
return stripped;
}
protected void handleCancel(ActionContext context,
ActionConfig actionConfig,
ActionForm actionForm)
throws Exception {
// do stuff
}
}
public class PopulateActionForm extends AbstractPopulateActionForm {
private static final Log log = LogFactory.getLog(PopulateActionForm.class);
protected void populate(ActionContext context,
ActionConfig actionConfig,
ActionForm actionForm) throws Exception {
// do stuff
}
protected void reset(ActionContext context,
ActionConfig actionConfig,
ActionForm actionForm) {
// do stuff
}
}
Why not do the following? Isn't that a better use of commons chain?
What are the experiences of the users of commons chain? Are there
any? ///;-)
SUGGESTED USE OF STRATEGY
public class PopulateActionForm implements Command {
private Helper helper;
public void setHelper(Helper helper) {
this.helper = helper;
public boolean execute(Context context) throws Exception {
// do stuff
helper.trimParameterName(actionCtx, actionConfig, actionForm);
helper.handleCancel(actionCtx, actionConfig, actionForm);
helper.reset(actionCtx, actionConfig, actionForm);
helper.populate(actionCtx, actionConfig, actionForm);
helper.handleCancel(actionCtx, actionConfig, actionForm);
return (false);
}
}
On Sun, 06 Mar 2005 09:14:50 -0500, Phil Steitz <ph...@steitz.com> wrote:
> Jack,
>
> Its best not to cross-post and when posting to one of the commons lists,
> you should start the subject line with the component name in brackets.
>
> I can assure you that there is no "closed shop of ideas" here. Posts
> are sometimes missed or misunderstood and sometimes the ideas don't
> resonate with others in the community. Nonresponse does not mean that
> the community is not open to new ideas.
>
> If your questions or suggestions for improvement are about the
> implementation of [chain], it might be better to post them to
> commons-dev and/or open a Bugzilla ticket including patches showing what
> you have in mind.
>
> Thanks!
>
> Phil
>
> 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: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
[chain] Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Phil Steitz <ph...@steitz.com>.
Jack,
Its best not to cross-post and when posting to one of the commons lists,
you should start the subject line with the component name in brackets.
I can assure you that there is no "closed shop of ideas" here. Posts
are sometimes missed or misunderstood and sometimes the ideas don't
resonate with others in the community. Nonresponse does not mean that
the community is not open to new ideas.
If your questions or suggestions for improvement are about the
implementation of [chain], it might be better to post them to
commons-dev and/or open a Bugzilla ticket including patches showing what
you have in mind.
Thanks!
Phil
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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Dakota Jack <da...@gmail.com>.
With all due respect, Bill, I don't think this is quibbling. The
actual use of these patterns has far-reaching consequences and this
"loose" way of talking about them IMHO is not helpful. For example,
if the RequestProcessor were a template, it would have *had* to have
been plugged into the framework differently, Bill. That's the point.
This different way of plugging it in would have very helpful
repercussions. Templates *enforce* an algorithm that subclasses must
override. They don't just have an algorithm that subclasses might
override. This enforcement is important. It is as important as the
enforced encapulation in OOP. I can remember when people in
procedural programming were saying, and still do, "C'mon, man, for all
intents and purpse its the same thing": you are just enforcing what we
do anyway.
Well, it isn't the same at all. Just imagine that there were a real
abstract class that was in the code in Struts and that the existing
RequestProcessor were the concrete implementation of the class.
Notice what would *have* to be changed and the options that would
suddenly be available. That is what is important and is what the
pattern does for you. I think that if you do this in your mind you
might agree on this point.
On the other score, i.e. Template Method and Strategy, I was
responding to real problems that have been discussed in relation to
the use of the commons-chain with the template method on the dev list.
I am not just talking philosophy here. The developers have run into
what I think are serious problems. I think they think so too. They
think so enough that some are having second thoughts about whether
using chain for these purposes will work well.
Jack
<SNIP>
On Mon, 7 Mar 2005 16:04:12 -0500, Bill Siggelkow
<bi...@bellsouth.net> wrote:
> C'mon man, for all intesive purposes its a Template -- it defines an
> algorithm that subclasses can override. As far as a way to specific
> alternative implementations -- there is, the <controller> element. But
> to me this whole conversation is moot. IMO, chain alleviates theses
> issues ... if you don't like how locale's are processed -- write your
> own class and all you have to do is implement Command (or use a number
> of other approaches). The use of the template method w.r.t to Struts
> use of chain is not something that I see as overly problematic --
> unless you think that any use of inheritance is wrong.
>
</SNIP>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Bill Siggelkow <bi...@bellsouth.net>.
C'mon man, for all intesive purposes its a Template -- it defines an
algorithm that subclasses can override. As far as a way to specific
alternative implementations -- there is, the <controller> element. But
to me this whole conversation is moot. IMO, chain alleviates theses
issues ... if you don't like how locale's are processed -- write your
own class and all you have to do is implement Command (or use a number
of other approaches). The use of the template method w.r.t to Struts
use of chain is not something that I see as overly problematic --
unless you think that any use of inheritance is wrong.
On 2005-03-07 11:37:33 -0500, Dakota Jack <da...@gmail.com> said:
> Hi, Joe,
>
> The RequestProcesser could have been but is not related at all to the
> Template Method pattern. More on that below.
>
> The real reason for this discussion is the following. It is fine that
> we are temporarily using the Template Method with CoR from
> commons-chain to solve the problems Template Method causes. However,
> those problems don't go away. I would hate to see and think I see
> some "hacks" being planned to accommodate the weakness of the Template
> Method. I am suggesting that rather that accommodate the weaknesses
> with the "hacks", it would be better to refactor to Strategy and avoid
> the difficulties.
>
> I am talking about the org.apache.struts.action.RequestProcessor. The
> Template Method pattern is built on an abstract class which implements
> program specific responsibilities as abstract methods or as a
> template. That is why it is called "Template Method". If the
> RequestProcessor had the method process(...) and then various program
> specific responsibilities like processLocale(...),
> processContent(...), processNoCache(...), processPreprocess(...),
> processRoles(...), processValidate(...), and so on as abstract
> methods, then it would be an example of the Template Method pattern.
>
> That the RequestProcessor class is a class that *could be* a concrete
> subclass of an abstact class that *could be* a template method class
> for the RequestProcessor does not help. THE MAIN REASON WHY THAT DOES
> NOT HELP IS THAT THE ABSENCE OF ANY ABSTRACT CLASS IN THE MIX MAKES
> THE USE OF ALTERNATIVE SUBCLASSES IN THE FRAMEWORK NOT PART OF THE
> PLANNING AND AT BEST DICEY. The RequestProcessor is just another java
> class that could have and maybe should have been fancier, but isn't.
> That's my take, anyway.
>
> If you had wanted to use the Method Template pattern here, then, the
> idea would have been to provide an abstract class for RequestProcessor
> with the logic of the process method implemented with abstract
> methods. Then, there could have been a default concrete subclass that
> implemented the abstract methods and a framework basis for
> substituting alternative implementations of the abstract class. This
> would not be a "monolithic" class, by the way, unlike the present
> RequestProcessor. "Monolithic" is not just large but large and rigid.
> The only fault, in my opinion, of any consquence in the existing code
> is its rigidity.
>
> Once again, I might have some time soon to offer a refactoring of the
> proposed chain in Struts supplanting the RequestProcessor class into a
> Strategy method. The process is almost as easy as a typing process,
> actually. There is nothing to doing it, except the time. I don't
> have that at the moment.
>
> I take it we can agree on this much? I am agreeing with you that the
> RequestProcessor is "related" to the Template Method pattern only
> insofar as it *could have been" but was not borken down into abstract
> methods that implemented the process(...) method's process.
>
> Jack
>
>
> <SNIP>
> On Mon, 7 Mar 2005 09:38:59 -0600, Joe Germuska <Jo...@germuska.com> wrote:
>>> I have no idea why Craig would say that the RequestProcessor is
>>> somehow related to the Template Method pattern. It just isn't.
>>
>> Are you talking about org.apache.struts.action.RequestProcessor?
>> Even if its not a shining textbook example of "Template", it most
>> certainly is related to that pattern. The "process(...)" method
>> defines a sequence of operations as a number of method calls, and the
>> indicated mechanism for extending the request process is to
>> selectively implement changes to only those methods which you need to
>> change, leaving "process()" as the "template" for normal operations.
>>
>> The implementation of ComposableRequestProcessor leaves this pattern
>> behind, as it reimplements the template method itself using almost
>> none of the methods which were originally intended to define the
>> request process. Maybe that's what you mean when you say that "it
>> just isn't"?
> </SNIP>
>
>
>
>
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Dakota Jack <da...@gmail.com>.
Hi, Joe,
The RequestProcesser could have been but is not related at all to the
Template Method pattern. More on that below.
The real reason for this discussion is the following. It is fine that
we are temporarily using the Template Method with CoR from
commons-chain to solve the problems Template Method causes. However,
those problems don't go away. I would hate to see and think I see
some "hacks" being planned to accommodate the weakness of the Template
Method. I am suggesting that rather that accommodate the weaknesses
with the "hacks", it would be better to refactor to Strategy and avoid
the difficulties.
I am talking about the org.apache.struts.action.RequestProcessor. The
Template Method pattern is built on an abstract class which implements
program specific responsibilities as abstract methods or as a
template. That is why it is called "Template Method". If the
RequestProcessor had the method process(...) and then various program
specific responsibilities like processLocale(...),
processContent(...), processNoCache(...), processPreprocess(...),
processRoles(...), processValidate(...), and so on as abstract
methods, then it would be an example of the Template Method pattern.
That the RequestProcessor class is a class that *could be* a concrete
subclass of an abstact class that *could be* a template method class
for the RequestProcessor does not help. THE MAIN REASON WHY THAT DOES
NOT HELP IS THAT THE ABSENCE OF ANY ABSTRACT CLASS IN THE MIX MAKES
THE USE OF ALTERNATIVE SUBCLASSES IN THE FRAMEWORK NOT PART OF THE
PLANNING AND AT BEST DICEY. The RequestProcessor is just another java
class that could have and maybe should have been fancier, but isn't.
That's my take, anyway.
If you had wanted to use the Method Template pattern here, then, the
idea would have been to provide an abstract class for RequestProcessor
with the logic of the process method implemented with abstract
methods. Then, there could have been a default concrete subclass that
implemented the abstract methods and a framework basis for
substituting alternative implementations of the abstract class. This
would not be a "monolithic" class, by the way, unlike the present
RequestProcessor. "Monolithic" is not just large but large and rigid.
The only fault, in my opinion, of any consquence in the existing code
is its rigidity.
Once again, I might have some time soon to offer a refactoring of the
proposed chain in Struts supplanting the RequestProcessor class into a
Strategy method. The process is almost as easy as a typing process,
actually. There is nothing to doing it, except the time. I don't
have that at the moment.
I take it we can agree on this much? I am agreeing with you that the
RequestProcessor is "related" to the Template Method pattern only
insofar as it *could have been" but was not borken down into abstract
methods that implemented the process(...) method's process.
Jack
<SNIP>
On Mon, 7 Mar 2005 09:38:59 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> >I have no idea why Craig would say that the RequestProcessor is
> >somehow related to the Template Method pattern. It just isn't.
>
> Are you talking about org.apache.struts.action.RequestProcessor?
> Even if its not a shining textbook example of "Template", it most
> certainly is related to that pattern. The "process(...)" method
> defines a sequence of operations as a number of method calls, and the
> indicated mechanism for extending the request process is to
> selectively implement changes to only those methods which you need to
> change, leaving "process()" as the "template" for normal operations.
>
> The implementation of ComposableRequestProcessor leaves this pattern
> behind, as it reimplements the template method itself using almost
> none of the methods which were originally intended to define the
> request process. Maybe that's what you mean when you say that "it
> just isn't"?
</SNIP>
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Erik Weber <er...@mindspring.com>.
Joe Germuska wrote:
>> I have no idea why Craig would say that the RequestProcessor is
>> somehow related to the Template Method pattern. It just isn't.
>
>
> Are you talking about org.apache.struts.action.RequestProcessor? Even
> if its not a shining textbook example of "Template", it most certainly
> is related to that pattern. The "process(...)" method defines a
> sequence of operations as a number of method calls, and the indicated
> mechanism for extending the request process is to selectively
> implement changes to only those methods which you need to change,
> leaving "process()" as the "template" for normal operations.
>
>
> Joe
>
Yeah Craig was just making that illustration for my benefit if I'm not
mistaken, because I asked someone to draw me a picture. So Jack, don't
discourage him. ;)
Also Jack, thanks for the detailed responses to my questions.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Joe Germuska <Jo...@Germuska.com>.
>I have no idea why Craig would say that the RequestProcessor is
>somehow related to the Template Method pattern. It just isn't.
Are you talking about org.apache.struts.action.RequestProcessor?
Even if its not a shining textbook example of "Template", it most
certainly is related to that pattern. The "process(...)" method
defines a sequence of operations as a number of method calls, and the
indicated mechanism for extending the request process is to
selectively implement changes to only those methods which you need to
change, leaving "process()" as the "template" for normal operations.
The implementation of ComposableRequestProcessor leaves this pattern
behind, as it reimplements the template method itself using almost
none of the methods which were originally intended to define the
request process. Maybe that's what you mean when you say that "it
just isn't"?
>As Ted said and whch makes sense to me, in another thread that is
>currently winding down:
Yes, once again, Ted eloquently summarized how we work. Thanks, Ted.
It lets me just say "what he said."
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Dakota Jack <da...@gmail.com>.
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 <er...@mindspring.com> 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 <er...@mindspring.com> 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: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Erik Weber <er...@mindspring.com>.
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 <er...@mindspring.com> 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: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Dakota Jack <da...@gmail.com>.
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 <er...@mindspring.com> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Erik Weber <er...@mindspring.com>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Craig McClanahan <cr...@gmail.com>.
On Sat, 5 Mar 2005 20:34:06 -0800, Dakota Jack <da...@gmail.com> wrote:
> I inquired why the Template Method pattern is being used with Commons
> Chain instead of Strategy, but never got an answer.
Back in town (for at least one day), and snipping off the flamebait
:-), it's worth philosophizing for just a coule of minutes.
Choosing between CoR, Strategy, and Template patterns is, at least
partly, a choice of the fine-grainedness you want for your abstraction
that is the basis for reusability. In Struts 1.1/1.2, for example,
one could consider the monolithic RequestProcessor class to be an
example of the Template approach (although it mashes the abstract base
class and default concrete implementation into a single class that you
can override and specialize). A strategy pattern approach to that
would have been to define RequestProcessor as an interface, perhaps
with a separate default implemetation, but you're at pretty much the
same point either way -- the set of steps (in the case of Struts, the
identity and ordering of the processXxx methods) is pretty much fixed,
and you've got a very coarse-grained replacement abstraction.
CoR as a pattern goes all the way to the other extreme, and tries to
make the unit of replacement as fine grained as possible. Not only
are the individual steps small and relatively independent (the linkage
between them is knowing the keys in the context that they use to pass
information back and forth), but you are completely free to change the
order of the steps, insert new steps, or omit steps you don't need.
If you are disciplined about how you construct your steps, this can
give you a pretty significant degree of reuse. For example, assume
you're building a CRUD type application by doing direct SQL through a
JDBC connection (whether that's a good idea or not is totally
immaterial to the illustration -- just pay attention to the philosophy
here). One might construct individual steps like this (for an update
transaction):
Initial state - primary key of the row you're going to update is in
the context under a well-known key. The updated fields are available
in other places (as a DTO, as a bunch of individual properties, or
whatever) that are also well known.
(a) Acquire a JDBC connection somehow, and store it in the context
(b) Based on the primary key (from the context), retrieve the current
data for the master row you're going to update
(c) Check the timestamp in the retrieved data to make sure nobody
else has updated the row first, while you were away
(d) Perform the appropriate updates
(e) Commit the transaction
(f) Release the JDBC connection back to where it came from.
With fine grainedness like this, you can easily reuse *portions* of
this business logic, with several variations on the theme:
* Steps (a) and (f) are reusable for any sort of transaction
that talks to this database. They are mutually interdependent,
which leads to a design choice discussed further below.
* You can have an implementation of (a) and (f) that grabs
something out of a JNDI-accessed data source for use in a
webapp, and a separate implementation that just reuses the
same Connection instance for a batch application, without
the rest of the chain knowing anything.
* Step (b) can be reused for any transaction that requires
retrieving the existing information from this particular table.
It doesn't care what happens after it's done its work -- that
is for the rest of the chain to determine.
* Step (c) is totally optional if you're working in an environment
where you don't have to worry about intervening updates, so
you could leave it out of a chain executed in that area.
* Step (d) is normally specific to the particular chain you are
executing, but it might still be reusable if you have more than
one business transaction that, perhaps, updates different
subsets of all the columns in this row.
* Making step (e) separate lets you construct chains that
update an arbitrary number of different rows in the same
SQL transaction, without the individual updates having to
be aware of any of the others.
In a large administrative app, you might construct hundreds of chains
like this (or define subchains that are executed via something like
LookupCommand to reduce the tedium of configuration) and have a large
degree of reuse over the set of individual command implementations.
And those same commands can be reused again in a batch app, or on the
back end of a web service, or at the back end of a request from client
JavaScript using XmlHttpRequest, or from anything else. As an extra
added benefit, writing unit tests for such fine grained things is very
easy ... just set up a context with the required incoming information,
execute the command, and check the results for the required
postconditions.
Think of the individual steps as LEGOs, plastic building blocks which
can snap together in all sorts of combinations, but only at certain
well-defined interface points (i.e. with some way to know what context
keys are used to pass in the input state and pass out the output
state).
The Template Method approach (and Strategy, for that matter, although
to a lesser degree) make more sense (at least to me) when you have a
set of interrelated operations that can be performed on some thing,
*and* the set of operations is the same for all potential
implementations of sets of those operations. You also have to deal
with the impacts of changes to the interfaces to these sets (for
example, adding a method to a Java interface is likely to break all
existing implementations, unless they all happen to subclass a common
base class where you can provide default behavior.
That all being said, I'm not ever going to use things like
org.apache.commons.chain.generic.DispatchCommand or
org.apache.commons.chain.DispatchLookupCommand myself -- mixing
metaphors :-) like this gives up some of the reusability I'm after
when I choose a CoR pattern in the first place. But I could see why
someone might want to do this, in the example above, to combine (a)
and (f) into a single source class because there is a 1:1 relationship
between the implementations of each step (for any possible overall
approach to acquiring connections).
At a pragmatic level, that's the sort of relationship I would document
in instructions to the architects assembling chains, rather than
embedding in the structure of the code. Others may see that
differently, which is why frameworks sometimes have to accomodate
different strokes for different folks.
Craig
PS: Pedantically, one could argue that CoR as implemented in [chain]
is one single implementation of the Strategy pattern that can be
reused by everyone -- in the pointed-at diagram of the pattern,
replace the word "Strategy" with "Command" and "AlgorithmInterface"
with "execute" :-). But that's a discussion that doesn't lead
anywhere useful, so I won't be bothered to discuss it again. As the
Javadocs tell you, [chain] was specifically intended to be an
implementatin of the Chain of Responsibility pattern as described in
the GoF book.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Dakota Jack <da...@gmail.com>.
I think Eric is too modest. This is much deeper than the sugar and
vinegar he gives himself credit for. This is positively Sid Hartha!
///;-)
On Sun, 6 Mar 2005 23:36:00 +0100, Leon Rosenberg
<st...@anotheria.net> wrote:
>
> > Everything good in the world starts with a desire to see
> > others succeed.
> >
> > Erik
>
> After a very calm Sunday (I already checked my email server twice, wondering
> how one could live without new
> mails to this list) we are starting with a philosophical discussion? :-)
>
> Regards
>
> Leon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
AW: Why Template Method instead of Strategy in Commons Chain?
Posted by Leon Rosenberg <st...@anotheria.net>.
> Everything good in the world starts with a desire to see
> others succeed.
>
> Erik
After a very calm Sunday (I already checked my email server twice, wondering
how one could live without new
mails to this list) we are starting with a philosophical discussion? :-)
Regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Erik Weber <er...@mindspring.com>.
Dakota Jack wrote:
>You are probably right, Bill. How to approach this has been a mystery
>to me.
>
Everything good in the world starts with a desire to see others succeed.
Erik
>But, I do think you are right about this and probably this is
>really ineffective.
>
>Jack
>
>
>On Sun, 6 Mar 2005 17:00:41 -0500, Bill Siggelkow
><bi...@bellsouth.net> wrote:
>
>
>>Michael -- I mean Dakota -- whatever ... as long as you continue
>>publish "baiting" posts like this my guess is that people won't want to
>>give you the time of day.
>>
>>On 2005-03-05 23:34:06 -0500, Dakota Jack <da...@gmail.com> said:
>>
>>
>>
>>>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: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Dakota Jack <da...@gmail.com>.
You are probably right, Bill. How to approach this has been a mystery
to me. But, I do think you are right about this and probably this is
really ineffective.
Jack
On Sun, 6 Mar 2005 17:00:41 -0500, Bill Siggelkow
<bi...@bellsouth.net> wrote:
> Michael -- I mean Dakota -- whatever ... as long as you continue
> publish "baiting" posts like this my guess is that people won't want to
> give you the time of day.
>
> On 2005-03-05 23:34:06 -0500, Dakota Jack <da...@gmail.com> said:
>
> > 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Bill Siggelkow <bi...@bellsouth.net>.
Michael -- I mean Dakota -- whatever ... as long as you continue
publish "baiting" posts like this my guess is that people won't want to
give you the time of day.
On 2005-03-05 23:34:06 -0500, Dakota Jack <da...@gmail.com> said:
> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Why Template Method instead of Strategy in Commons Chain?
Posted by Dakota Jack <da...@gmail.com>.
I guess I focused on the "backward compatibility" issue, which I did
not understand at all. Thanks.
On Sun, 6 Mar 2005 19:09:45 -0500, Ted Husted <te...@gmail.com> wrote:
> Joe and Bill did respond.
>
> * http://www.mail-archive.com/dev%40struts.apache.org/msg07346.html
>
> I don't think anyone is opposed to use Strategy more often. (Heaven
> knows I use it often enough in my own work!)
>
> It's just that no one seems to have the volunteer hours available
> right now to refactor what we already have.
>
> What we have is ugly and problematic, but I believe that it does work.
> If we ship it, perhaps someone (like you) will step up and refactor it
> for Strategy.
>
> -Ted.
>
>
> On Sat, 5 Mar 2005 20:34:06 -0800, Dakota Jack <da...@gmail.com> 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.?
> >
> > --
> > "You can lead a horse to water but you cannot make it float on its back."
> > ~Dakota Jack~
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org