General talk about software patterns

[<sayan.mukherjee AT iflexsolutions.com>]

Hi Sourav,

 

Re:(a) and (c)

The GoF text on the Strategy pattern speaks only of a single Context object that needs to switch across

a set of ConcreteStrategy objects, all of which conform to the AbstractStrategy interface. Implicitly it

assumes that the different concrete class methods implementing the different algorithms have uniform

signature to conform to the AbstractStrategy.

 

If we assume that

 

(the input data to the algorithm)

    is equals to

(a set of parameters to the method in the relevant Strategy subclass),

 

then one way of bringing in uniformity is have a hierarchy of the input values.

 

Typically they may be a set of concrete classes with public data, each being a child of an empty abstract

class. This way the context hierarchy may not be required. (Example below, after this message ends)

 

Since in (c) you have mentioned that the inputs are well-defined but have variety, this plan may help.

 

 

Re:(b)

Can you kindly give an example how you will use Factory in conjunction with Strategy?

 

You have also mentioned:

"client is protected from knowing about the specific classes which implement specific algorithms"

 

Are you referring to the use of a StrategyFactory where the product is a Strategy object?

 

With best regards,

Sayan

 

P.S. Apologies for the oversized email!

 

 

#################################

Example:

/********************************************/

<<abstract>> class AbsData

    Attributes:

    Methods:

 

class Data1 : public AbsData

    Attributes:

        + int x;

        + int y;

    Methods:

 

class Data2 : public AbsData

    Attributes:

        + float x;

        + double d;

        + int z;

    Methods:

/********************************************/

 

<<abstract>> class AbsStrategy

    Attributes:

    Methods:

        + void f(AbsData *);

 

class Strategy1 : public AbsStrategy

    Attributes:

    Methods:

        + void f(AbsData *)

        {

            // algo implementation

        }

 

class Strategy2 : public AbsStrategy

    Attributes:

    Methods:

        + void f(AbsData *)

        {

            // algo implementation

        }

/********************************************/

 

Usage:

AbsData * d =  new Data1();

AbsStrategy * s = new Strategy1();

s->f(d);

 

If later we want to change to another algo (encapsulated in the other Strategy class):

AbsData * d =  new Data2();

AbsStrategy * s = new Strategy2();

s->f(d); // The call remains the same

 

End of example

#################################

 

 

---

From: souravm [mailto:SOURAVM AT infosys.com]
Sent: Thursday, September 23, 2004 11:08 AM
To: patterns-discussion AT cs.uiuc.edu
Subject: [patterns-discussion] Doubts regarding Strategy Pattern

Hi All,

 

I’ve some doubts regarding Strategy pattern.

 

a)      One almost always needs a Context hierarchy corresponding to the Strategy hierarchy. This is because, when an algorithm changes, the input data it needs will also be different. So is this an acceptable and common modification of the Strategy pattern? And are there any side effects of the same? b)      Isn't it advisable to use Factory in conjunction with Strategy pattern so that client is protected from knowing about the specific classes which implement specific algorithms? c)      If I have a situation where module have fairly well-defined input but that input can come in a variety of ways - e.g., through the database, on a message queue or directly from presentation tier through a DTO, etc. - then is there a well known pattern to use to model this?

 

Any pointer/inputs on this will be really appreciated.

 

Regards,

Sourav

 

 

DISCLAIMER:
This message contains privileged and confidential information and is intended only for the individual named.If you are not the intended recipient you should not disseminate,distribute,store,print, copy or deliver this message.Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted,corrupted,lost,destroyed,arrive late or incomplete or contain viruses.The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.