From: Kenosis <kenosis@...>
Date: 2006-08-22T04:35:07+09:00
Subject: Re: Strategy pattern / interface design arrangement


Daniel Waite wrote:
> Robert Klemme wrote:
> > 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).
>
> I realize Ruby doesn't explicitly support the concept of an interface
> via a keyword (convention over configuration anyway, right?). However,
> that doesn't mean I can't program inline with the _concept_ of an
> interface. The _concept_ of design by contract. It's those concepts I'm
> trying to utilize because I believe they're helpful.
>
> > Second, nesting the "interface" and classes that implement
> > it seems weird to me.
>
> That's the hallmark of the Strategy pattern.
>
> > 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.
>
> Yes and no. Mostly no in my situation. The point of using an interface
> _in this case_ is to encapsulate a defined set of behaviors into many
> possible implementations. We may well add another payment processor to
> our arsenal later down the road. Provided the interface is strong enough
> I should be able to code to that interface and not be able to tell which
> implementation I'm using.
>
> > Why does Company include CreditCardProcessor if it's just an interface?
>
> To this end I'm not certain. Looking at my examples again I suppose it
> doesn't make much sense to include it into Company.
>
> CreditCardProcessor.process_credit_card(@company.credit_card, order)
>
> Would make more sense. Or does it? :(
>
> Ilan Berci wrote:
> > Some of the GOF patterns don't translate to a dynamically typed language
> > such as Ruby.
>
> What's GOF?
>
> > With duck typing, there is no need to explicitly set the
> > interface that the internal strategy component will adhere to and your
> > implementation is free to swap strategy components just as you would in
> > a statically typed language but with the added flexibility of not having
> > to explicitly set the interface before hand..
>
> Not only is there no need, there's no way to explicitly set the
> interface in Ruby. But I want to act as though it's explicit, that it
> must be adhered to.
>
> snacktime wrote:
> > I would probably not put CreditCardProcessor inside Company.  I would
> > leave it as a stand alone module and call it when needed.
>
> Aye, I think I'm with you on this. Thanks! :)
>
> --
> Posted via http://www.ruby-forum.com/.

GOF = Gang of Four (the authors of the "original" Design Patterns"
text.)