Re: OO Architecture

On Wed, Sep 28, 2005 at 06:54:56PM +0200, Honza Pazdziora wrote:
> On Wed, Sep 28, 2005 at 05:06:02PM +0100, Tim Bunce wrote:
> > > three modules of which each provides single modification and which can
> > > be used together or one at a time.
> > 
> > (That scenario matches the pick-n-mix merging of roles I mentioned in
> > my recent post.)
> 
> It looks like I'll have to study the roles synopsis in depth.

We all will :)

> > > how do you do multiple inheritance? One module modifying your parsing,
> > > another one modifying your logging behaviour ... Currently you have to
> > > create a single module that combines both behaviours, don't you?
> > 
> > Yes for DBI v1. For v2 goal 9 comes into play:
> > 
> >   9. Define the DBI and drivers in terms of multiple interfaces to simplify
> >      reuse or replacement of components.
> > 
> > I'll pad that out a bit more but basically things like pre-processing
> > sql, logging, error handling etc., will all be separate classes and a
> > handle will have objects of each that it'll call methods on as needed.
> 
> And a subclass will either define its own classes for these tasks, or
> inherit the default provided by DBI?

Yes :)

> > So it'll be much easier to switch to alternate implementations of
> > individual components (or subclasses of the default components :).
> 
> Still, how do you use those subclasses? Let's say that you want to use
> DBI, plus two classes of which each does something to logging (provide
> its own subclass of the loggin class). How will their mutual
> precedence get resolved?

We're putting the cart before the horse here slightly. It's too soon to
determine best practices for this or realistic scenarios.

If pick-n-mix merging of roles works as I hope it will then I'd expect
they'll be more roles that do less. Finer granularity. So an application
can ask for specific individual roles - and so ask for the logging role
from only one of the two in your example. [This is getting very hand-wavy.]

You could say that "subclassing the DBI" becomes less meaningful once
"the DBI" has been broken out into many classes (roles). We'll need to
start talking about "subclassing DBI connections", "subclassing DBI
statements", "subclassing DBI logging" etc.

Given that re-frameing, your question would also need re-frameing.
Given all the hand waving I think it's probably best to shelve it for now.
We'll certainly need to address it later.

> > > Being able to do something before, after and instead of a particular
> > > DBI call.
> > 
> > Subclassing gives you that.
> 
> But only for cases when I write my own subclass. Not when I'd like to
> use a couple of "subclasses" (behaviour modifiers) from CPAN.

That's where Perl6 Roles come in. Roles allow dynamic composition of
behaviours (think mix-ins on steriods).

The big problem with subclassing is that if modules B and C both
subclass A then it's very hard to use both B and C at the same time.
Roles get around that problem, and others.

Tim.