> -----Original Message-----
> From: Dakota Jack [mailto:[EMAIL PROTECTED]
===////===
>
> 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
>
Consider a GUI algorithm that displays rows from the database.
The typical problem is to work out the best column width for
rendering the screen.
interface IFormatDatabaseColumnWidth {
public int calcColumnWidth( Object[][] data, MetaData metaData[], int
columnNo );
}
// Slowest and most accurate algorithm iterates all rows in the result set
class AllRowsFDCW implements IFrameDatabaseColumnWidth { ... }
// Algorithm based on the first 100 rows
class First100FDCW implements IFrameDatabaseColumnWidth { ... }
// Algorithm that calculates the column width for every N rows
class StepwiseFDCW implements IFrameDatabaseColumnWidth { ... }
This is the classic strategy pattern, as I remember writing it in a Swing/JDBC
five years ago. (In fact Xenon-SQL is still out there somewhere, but it
is broken against JDK 1.3 and 24/7/365 the time to fix it! )
You can rewrite the above strategy with Chain of Responsibility
pedantically. If you have a very functional requirement for it.
class ChainFDCW implements IFrameDatabaseColumnWidth {
Catalog catalog;
String commandName;
// IoC container friendly
public void setCatalog( catalog ) { ... }
public void setCommandName( name ) { ... }
public int calcColumnWidth( Object[][] data, MetaData metaData[], int
columnNo )
{
Context context = new FDCWContext( data, metaData, columnNo );
Command command = catalog.getCommand( commandName );
command.execute( context );
if ( context.isCalculatedOk() )
return context.getColumnWidth();
else
throw new StrategyRuntimeException(
"Failed to calculate column width" );
}
}
Ok writing a CoR for calculating data width takes a bit of stretching
the imagination, but of course you can do it, which is the point.
> 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~
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
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]
