General talk about software patterns

[Ralph Johnson <johnson AT cs.uiuc.edu>]

On 9/23/04 12:38 AM, "souravm" 
<SOURAVM AT infosys.com>
 wrote:

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

No, this is neither acceptable nor common.  The whole point of Strategy is
that you have to figure out a single interface that all the strategies can
use.  In general, you will generalize and abstract the interface.  The
interface might be a superset of what any one algorithm will need.  But all
the strategies must have the same interface so you can switch from one to
the other.

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

You can do it, but it usually isn't worthwhile.  The strategies are coupled
to the context and can't be reused without it.  So, if you want to make the
client of the context independent of the strategy classes, make some methods
on the context to switch to the new strategy.

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

Make an interface for the input.  Lets say we call it "Input".  Then give an
Input to your module.  The module will read from the Input.  Often an Input
is just a stream.  You can make different classes that support the Input
interface, one for data from the database, one from a message queue, etc.

-Ralph Johnson