I meant "I find your note interesting" and not "I find your not interesting".
On 5/31/05, Dakota Jack <[EMAIL PROTECTED]> wrote:
> Hi, Peter,
>
> I am not sure what you are saying here. I had trouble following you.
>
> The Strategy Pattern is roughly the following:
>
> public class DefaultStrategyInterface implements StrategyInterface {
> private Helper helper;
>
> public void setHelper(Helper helper) {
> this.helper = helper;
> }
>
> public void doWork() {
> // Do business logic
> int value = hleper.calculateSomething(params);
> // Do more business logic
> }
> }
>
> The Template Method Pattern used in Struts which necessitates the use
> of the Chain of Responsibility Pattern, cf.
> http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html, is
> roughly the following:
>
> public abstract class AbstractMethodInterface implements MethodInterface {
> public void doWork() {
> // Do some business logic
> int value = calculateSomething(params);
> // Do more business logic
> }
>
> protected abstract int calculateSomething(params);
> }
>
> So, in a real sense, the Strategy Pattern advocates, in comparison to
> the Template Method Pattern, composition over inheritance allowing for
> ease of testing and a host of other good results.
>
> Struts is based on the Template Method Pattern which Sigglelow rightly
> sees is rescued by the Chain of Responsibility Pattern. This is the
> context in which I was addressing the Strategy Pattern. Can you give
> a little demo of how CoR "metamorphasis's into this? I find your not
> interesting but cannot see what it means.
>
> Thanks
>
> On 5/31/05, Pilgrim, Peter <[EMAIL PROTECTED]> wrote:
> > > -----Original Message-----
> > > From: Dakota Jack [mailto:[EMAIL PROTECTED]
> > ==////==
> > >
> > >
> > > I should have added that Rod (Johnson) in the book cited pointedly
> > > advocates extensive use of the Strategy Pattern, see pp. 421 ff. The
> > > use of CoR in Struts 1.3 for the extensible RequestProcessor is not a
> > > feature but is a way of solving the problem created by the original
> > > use of the Template Method Pattern in that context. Had the Strategy
> > > Pattern been used in the first instance, everything would have worked
> > > better, in my opinion. In many ways, I think in the future the
> > > Template Method Pattern may be seen as an Anti-Pattern.
> > >
> > > Just to forestall flamethrowers, I want to emphasize that others
> > > probably think differently and even the "majority", i.e. by definition
> > > the members ipsa facto of the "meritocracy", may think differently.
> > > But, Rod Johnson is no slouch on these matters. He thinks the use of
> > > Strategy Pattern is "one of the reasons [Spring] is such a flexible
> > > and extensible framework".
> > >
> >
> > Hello Jack
> >
> > It can be shown that ``Chain of Responsibility'' pattern can be
> > metamorphed into the ``Strategy'' pattern. The first proviso is that one
> > of your commnds becomes a catalogy factory or invoker of other
> > generic commands itself. The second proviso is you must pass all
> > your information back and forward the ``strategy command'' using
> > a general context object.
> >
> > fyi
> >
> > > On 5/27/05, David Whipple <[EMAIL PROTECTED]> wrote:
> > > > This is an off topic post, but there seem to be a lot of
> > > people with good
> > > > opinions here.
> > > >
> > > > I am trying to provide a framework (based on Stuts and
> > > Spring) for our
> > > > company
> > > > to use. I'd like to make a reinforcement of the business layer in
> > > > applications.
> > > >
> > > > We do not use EJBs, so a lot of the patterns that are out
> > > there do not seem
> > > > to
> > > > apply. I have not been able to find any references I like.
> > > >
> > > > The goal is to encourage better program design and development by
> > > > having a clear definition of what are the business objects
> > > in the program.
> > > >
> > > > We want to come up with a way through patterns to help
> > > programmers avoid
> > > > poor
> > > > programming practices. Clear separation into layers is one
> > > basic idea
> > > > behind
> > > > this. We want to come up with some interface to the
> > > business layer which
> > > > will
> > > > force programmers to know what are to be the business
> > > objects in their
> > > > architecture.
> > > >
> > > > Does anyone have any ideas and/or know of any references for this?
> > > >
> > > > Thanks,
> > > > Dave
> >
> > ==////==
> >
> >
> > --
> > Peter Pilgrim
> > Operations/IT - Credit Suisse First Boston,
> > Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
> > Tel: +44-(0)207-883-4497
> >
> >
> > ==============================================================================
> > This message is for the sole use of the intended recipient. If you received
> > this message in error please delete it and notify us. If this message was
> > misdirected, Credit Suisse, its subsidiaries and affiliates (CS) do not
> > waive any confidentiality or privilege. CS retains and monitors electronic
> > communications sent through its network. Instructions transmitted over this
> > system are not binding on CS until they are confirmed by us. Message
> > transmission is not guaranteed to be secure.
> > ==============================================================================
> >
> >
> > ---------------------------------------------------------------------
> > 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~
>
--
"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]
