On 21.08.2006 07:55, Daniel Waite wrote:
> Hi all. I've got a design question.
> 
> Imagine you have a module, CreditCardProcessor. Inside 
> CreditCardProcessor is another module called AuthorizeNet. 
> CreditCardProcessor acts as an interface that AuthorizeNet must 
> implement. (This is, from what I understand, a reasonably accurate 
> implementation of the Strategy pattern (behavioral implementation behind 
> a common interface). However, if you feel I could be more accurate, 
> don't hesitate to say so. :)

I find it odd that AuthorizeNet is a module and that it's contained in 
CreditCardProcessor which you said defines the interface.  First, you 
don't have interfaces in Ruby (and you don't need them).  Second, 
nesting the "interface" and classes that implement it seems weird to me. 
    If we assume for the moment that we are using a language with 
interfaces then the main point of them is, that you can have arbitrary 
classes implement them.  And these classes can reside in whatever 
package or namespace.

> Now imagine we have a class named Acme that extends class Company. 
> Company includes CreditCardProcessor and has an instance variable called 
> @credit_card_processor.

Why does Company include CreditCardProcessor if it's just an interface?

> Now Acme has all the tools it needs to process cards. However, do we 
> say...
> 
> @company.process_credit_card(card) # A pass-through (convenience) method
> 
> .. or...
> 
> @company.credit_card_processor.process_card(card)
> 
> If you were designing (or have designed) such an arrangement, which is 
> your preferred method and why? (Or if you have an entirely different 
> suggestion I'm all ears.)

It always depends...  I'd probably go with the second approach because 
that does less cluttering of class Company's public interface / signature.

Kind regards

	robert