On 22.08.2006 02:00, Daniel Waite wrote:
> Rick Denatale wrote:
>> [A lot.]
> 
> Wow. Okay, your description of the Strategy pattern doesn't mean a lot 
> to me without an example. (Sorry if that sounds harsh; it's not my 
> intention.) Could you provide an example?

http://en.wikipedia.org/wiki/Strategy_pattern
http://c2.com/cgi/wiki?StrategyPattern

 > Are such patterns even worth
 > pursuing in Ruby?

Yes, but you have to adjust the implementation to the language at hand.

>> ... Modules in Ruby provide implementation, so they don't really
>> make good reifications of the concept.
> 
> We're using a module now, actually. In the event another payment 
> processor comes along do you feel it should simply be another module? 
> (That's interesting, that a module provides implementation. I've not 
> heard that said anywhere else, but maybe because it was considered 
> obvious?)

I really don't understand why you bring in modules here and seem to keep 
insisting on them.  Each strategy should be its own class IMHO.  You 
can, if you want to have some form of reuse or general behavior, give 
them all a common superclass.  But that's it.

>> Here I have to politely disagree.  The hallmark of the Strategy
>> pattern is the provision of a configurable service object (which the
>> GOF calls a Context) which clients can configure by giving it
>> different ConcreteStrategy objects, and the separation of
>> implementation of the Context and the various ConcreteStrategies,
>> through the use of an interface definition called a Strategy.
> 
> You're saying one class is given another, configurable class, which is 
> configurable by giving a ConcreteStrategy object? Example? :(

See the Wikipedia page.  "Context" in the UML diagram is your Company, 
"Strategy" is your Processor base class (if you have it at all).

> Confused, much! I suppose if I fall back on my earliest Ruby teachings, 
> modules implement behavior (e.g. Enumerable) and classes mix-in that 
> behavior. Gah... I'm reading three books and the information presented 
> is frying my brain. (Head First Design Patterns, XP Explained and Object 
> Thinking.)

I guess *this* is your real problem: you need some more understanding - 
once you get that all will be clear.

Kind regards

	robert