General talk about software patterns

["Sriram Gopalan" <Sriram.Gopalan AT agile.com>]

Hi Sourav,

    It is hard for me to imagine that the client would be totally insulated from the actual strategy if the inputs depend on the actual strategy being used! The key is to figure out if the various concrete strategies can be abstracted out as an AbstractStrategy or not.

    If yes, you shouldn't need to change the inputs since the contract that the client abides by is defined by the AbstractStrategy.

    If not, it might not be a proper use of the strategy pattern.

regards,

Sriram Gopalan

-----Original Message-----
From: souravm [mailto:SOURAVM AT infosys.com]
Sent: Wednesday, September 22, 2004 10:38 PM
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