Re: Which GoF Design Pattern to choose?
From: Rod Davison (critsys_at_rogers.remove.com)
Date: 02/06/04
- Next message: Darrell Grainger: "Re: I only program the C64"
- Previous message: Noah Roberts: "Re: PLEASE READ (was Re: recursive proofs)"
- In reply to: Timo Nentwig: "Re: Which GoF Design Pattern to choose?"
- Next in thread: Timo Nentwig: "Re: Which GoF Design Pattern to choose?"
- Reply: Timo Nentwig: "Re: Which GoF Design Pattern to choose?"
- Reply: Timo Nentwig: "Re: Which GoF Design Pattern to choose?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 06 Feb 2004 17:36:12 GMT
On Fri, 06 Feb 2004 09:18:52 +0100, Timo Nentwig wrote:
> Rod Davison wrote:
>
>> That look good to you?
>
> Yes, that's actually how I did it - but I am not sure whether this really
> is the Strategy pattern since - as I understand it - the Strategies ought
> to be exchangable. I.e. you may have a QuickSort Strategy, a BubbleSort
> Strategy. At least you can pass the same data to any Strategy and any
> Strategy can handle it.
>
> What I am esp. missing in the Strategy pattern is that I need logic to
> decide what kind of document I have, i.e.
>
> switch (docType)
> {
> case CNN: cnnStrategy(); break;
> case BBC: bbcStrategy(); break;
> ---
> }
> }
> This switch isn't part of the Strategy pattern (see GoF p. 318, first
> listing).
>
> Timo
This is why you introduce an abstract document class and then subclass
each type of document from it. The concrete subclasses then use
polymorphism to use the right parse() method.
The key to the strategy pattern is that you don't have to do that kind of
switching logic. each concrete document class encapsulates the logic to
figure out how to get the right parsing strategy. What you seem to have up
in your code above is still writing code to choose strategies, that should
have been delegated to the document objects.
I think the part that might be confusing you is when to create the
document object. I suspect that each text document comes from either a
different source or they all come from the same source with some
identifier preceding them. Again, the examples below are just off the top
of my head so the code is sloppy.
Suppose we have the first case. We create a docSource class.
interface docSource {
public document getDocument();
}
class bbcSource implements docSource {
private String getText() {/* logic to get text document from input stream */}
public document getDocument() {
return new bbcDocument(this.getTExt,new bbcParser());
}
}
then the code is used like
bbcSource bbcFeed = new bbcSource();
bbcDocument b = (bbcDocument) bbcFeed.getDocument();
b.parse();
or you could put a whole bunch of different documents in an array and just
iterate.
document [] d = new document[3];
d[0] = bbcFeed.getDocument();
d[1] = cnnFeed.getDocument();
d[2] = reuterFeed.getDocument();
for (int = 0; i < 3; i++) d[i].parse();
But you get the idea. BY instantiating the right kind of document object
when the text appears, you eliminate coding switch logic later.
-- ................................................. Whip me. Beat me. Make me maintain Windows. Rod Davison - Critical Knowledge Systems Inc.
- Next message: Darrell Grainger: "Re: I only program the C64"
- Previous message: Noah Roberts: "Re: PLEASE READ (was Re: recursive proofs)"
- In reply to: Timo Nentwig: "Re: Which GoF Design Pattern to choose?"
- Next in thread: Timo Nentwig: "Re: Which GoF Design Pattern to choose?"
- Reply: Timo Nentwig: "Re: Which GoF Design Pattern to choose?"
- Reply: Timo Nentwig: "Re: Which GoF Design Pattern to choose?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]