> -----Original Message-----
> From: Dakota Jack [mailto:[EMAIL PROTECTED]
==////==
> 
>     "Strategy (315) Define a family of algorithms encapsulate each
> one, and make them
>      interchangeable.  Strategy lets the algorithm vary independently
> from clients that use
>      it."
> 

This is exactly I always thought it was too.

> So, your point about the Strategy Pattern, of course, does not work
> and is a non-starter.
> 
> 

Yes I missed the ``StrategyContext'' the actual POJO or entity that
encapsulates the ``Strategy'' and de-couples from the POJO.
Because of this decoupling you can thus change the strategy and
therefore write a __crazy_frog__ implementation that calls chain
if you found a worthy cause for it.


> A Strategy Pattern most importantly introduces some Helper utility
> interface for the various implementations of an algorithm.  Thus, you
> could have either
> 
> A.  
> 
> interface IFormatDatabaseColumnWidth {
>     public void setHelper(Helper helper);
>     public void doWork();
> }
> 
> or
> 
> B.
> 
> Inteface IFormatDatabaseColumnWidth {
>     public void doWork();
> }
> 
> But the implementations would have to be something like:
> 
> public class IFormatDatabaseColumnWidthImpl {
>     private Helper helper;
> 
>     public void setHelper(Helper helper) {
>         this.helper = helper;
>     }
> 
>     public void doWork() {
>         // Do business logic
>         int value = helper.calcColumnWidth(data,metaData[]),columnNo);
>         // Do more business logic
>     }
> }
> 
> Thus, there would be a Helper interface:
> 
> interface Helper {
>      int calcColumnWidth(Object [][] data, MetaData 
> metaData[]) int columnNo);
> }
> 
> The differing calculations, then, would go into the Helper interface
> implementations and not into the IFormatDatabaseColumnWidth interface
> implementations.  So, you might have
> 
> public class AllRowsFDCW implements Helper {
>     public int calcColumnWidth(Object [][] data, MetaData metaData[])
> int columnNo) {
>          // Slowest and most accurate algorithm iterates all rows in
> the result set
>     }
> }
> 
> and 
> 
> public class First100FDCW implements Helper {
>     public int calcColumnWidth(Object [][] data, MetaData metaData[])
> int columnNo) {
>          // Algorithm based on the first 100 rows
>     }
> }
> 
> and 
> 
> public class class StepwiseFDCW implements Helper {
>     public int calcColumnWidth(Object [][] data, MetaData metaData[])
> int columnNo) {
>         // Algorithm that calculates the column width for every N rows
>     }
> }
> 
> Please note that the pattern essentially uses polymorphism and late
> binding not through implementations of an interface but through a
> composite pattern.
> 
> Thus, when inversion of control (IoC) is used with the Strategy
> Pattern, whether you are doing Dependency Injection (DI) or Dependency
> Lookup (DL), the Helper is what is the subject of the lookup or
> injection.  (IoC, including DL, cannot be identified as DI merely.)
> 
> Your explanation of the Strategy Pattern leaves out what is essential
> to the pattern.  Consequently, your explanation is merely how Chain of
> Responsibiltiy (CoR) can be used instead of differing implementations
> of an interface. See below for a short note on your CoR example.
> 

Dependency injection can be used anywhere where there is a public constructor
or JavaBean setters. If you are using strategy pattern that you are right
you can inject the ``strategy'' into the ``StrategyContext'' at run-time.

And in this case if you want to use CoR inside the ``StrategyContext''
 of course you need to write an adaptor for your algorithm interface
to call the first command of the Chain.

> 
> On 6/1/05, Pilgrim, Peter <[EMAIL PROTECTED]> wrote:
> > 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! )
> 
> SECOND PART: Ugh!
> 
>  In my opinion, by the way, as an aside, using the CoR to replace mere
> implementations of an interface would be rather *nuts*.  This would
> merely obfuscate and provide no benefit at all.  This is what our
> fellow traveler Frank Zammettie finds inherently suspicious about the
> *OOP nuts*.  This is, I am afraid, similar to some of the rather *knee
> jerk* uses of CoR floating around.  How does that old saw go?  A boy
> with a new hammer sees the whole world as a nail?
> 

Well I will disagree about the interface and the strategy. I can
envision a complex algorithm, which broken into steps. Suppose
one of these steps is long winded and time consuming, and
there was a quicker alternative, based on a fast look-up
table, then I can see a role for CoR sitting behind, if you
like, a Strategy.

If the algorithm was dynamic and the business wanted to
allow customer (or skilled assembler ) configuration. All I am
saying I can see some of sort of CoR being used with the 
Strategy pattern. There is almost bridging of the two patterns 
in the design, through my intuition and inspection at least.

I will let this rest now ... it metoerically blasting way off-topic 
for Struts User.

( I hope you agree, it is real eye opener for software architecture 
and design committees :-D )

==////==

--
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]

Reply via email to