[bop-devel] AuthorizeNet MD5 Check

[Ivan Kohler]

On Tue, Sep 25, 2007 at 01:09:56PM -0700, Bill Moseley wrote:
> On Tue, Sep 25, 2007 at 12:57:00PM -0700, Ivan Kohler wrote:
> 
> (moving to the list)
> 
> > > What's the recommended way to subclass a processor module?
> > 
> > I don't think that's recommended in the first place.  I can't say I've 
> > ever given it much thought.  The only time I've ever subclassed a 
> > processor module was for the Authorize.net compatible gateways, where I 
> > overrode the set_defaults method.
> > 
> > What are you trying to do?
> 
> Provide additional functionality.  For example, as I commented before,
> 
>     $tx->validate_md5( $secret );
> 
> or even just to override submit to include the md5 check.

This seems like you would modify the module itself, not write a separate 
class.

> Or other methods for, say, logging or wrapping up a transaction, for 
> example, as in my case, in a SOAP response.

And these seem more suited to a "using" relationship (where your code 
*uses* B:OP), not an "is-a" relationship.  :)

> The current method for loading processors complicates subclassing a
> bit.
> 
> Is there an advantage of doing:
> 
>     my $tx = Business::OnlinePayment->new( 'AuthorizeNet' );
> 
> vs.
> 
>     my $tx = Business::OnlinePayment::AuthorizeNet->new;

Yes, the advantage is very much the whole reason why we have a class of 
modules within a framework and not disparate modules.

   my $tx = Business::OnlinePayment->new( $processor, %options );

is better than:

  my $tx = eval "Business::OnlinePayment::$processor->new( \%options )";
  die $@ if $@;

> Which would facilities subclassing.

Subclassing is not a public interface of the B:OP modules.  :)

-- 
_ivan