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? Are such patterns even worth 
pursuing in Ruby?

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

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

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.)

Anywho, thanks for all the help thus far. :)

-- 
Posted via http://www.ruby-forum.com/.