struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dakota Jack <>
Subject Re: Why Template Method instead of Strategy in Commons Chain?
Date Mon, 07 Mar 2005 16:37:33 GMT
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
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.


On Mon, 7 Mar 2005 09:38:59 -0600, 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.
> 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"?

"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message