Re: Picking the Tools -- Marrying processing models to data models

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

> > My point is that you can get all the benefits of swapping in the Customer
> > code without late binding tied exclusively to inheritance.  IOW,
> > polymorphism is much bigger than OO.
>
> Gimmee an example, I don't totally follow you...

Here's somthing in Python, a language, remember, that is basically OO but
gives you plenty of escape hatches from OO when you need them.


old classes:

class UUCPEmailer:
    def sendMessage(self, email, msg):
        #do your UUCP magic here
        pass


class Customer:
    #Basically a static class variable
    emailMixin = UUCPEmailer()

    #Basically a constructor
    def __init__(self, name, email):
        self._name = name
        self._email = email
        return

    def sendBulletin(self, msg):
        self.emailMixin.sendMessage(self.email, msg)

So now we've changed our entire systems and we use SMTP for e-mail rather
than UUCP.  Never fear, there are myriad ways to re-use our customer code.
One is

class SMTPEmailer:
    def sendMessage(self, email, msg):
        #do your SMTP magic here
        pass

Customer.emailMixin = SMTPEmailer()

And that's it.  We changed a core aspect of the system without needing to
scrap the customer code.  No OO involved, just techniques familiar to
any library.  We implemnented late binding through metaprogramming rather
than inheritance polymorphism.  This sort of thing is a snap, and I do it
quite often without needing inheritance or limited polymorphism, because
my language of choice allows me to.

In my example I mixed-in functionality through association.  I could have
done it with inheritance as well, using Inheritance-based Mixins:

class UUCPEmailerMixin:
    #The underscore sort of makes it a private method
    def _sendMessage(self, email, msg):
        #do your UUCP magic here
        pass


#Inherit from UUCPEmailerMixin
class Customer(UUCPEmailerMixin):

    #Basically a constructor
    def __init__(self, name, email):
        self._name = name
        self._email = email
        return

    def sendBulletin(self, msg):
        self.emailMixin._sendMessage(self.email, msg)

After the migration to SMTP:

class SMTPmailerMixin:
    #The underscore sort of makes it a private method
    def _sendMessage(self, email, msg):
        #do your SMTP magic here
        pass

#Note the order of inheritance, due to Python look-up rules
class NewCustomer(SMTPmailerMixin, Customer)
    #That's *all* that is required of the new class body
    pass


I could also have done this with delegation or even the most primitive
method of polymorphism: dynamically swapping in a new sendMessage method
body for Customer at run-time.

All very simple, really.  No great insights I offer.  Just a reminder that
all of this is soup without One Methodology to Rule Them All.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python