Re: OO Architecture

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.

> > 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?

> 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?

> > 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 sounding more like chains of handlers, ala Apache.
> That's unlikely to be in the core, but a subclass could implement it :)
> I've just added a new goal:
> 
>  15. Keep the core DBI as small and simple as possible, but no simpler.
>      If it can be done outside the core then it probably should.

It's a wise goal. Since we can subclass the core at any time and do
all the extensibility actions in that subclass, we do not need to deal
with it in the core at all. ;-)

> > If I'm later going to make a subclass, by naming those changes
> > and putting them into a single module is just a nice final touch. But
> > in many cases, you actually do not need and do not want to subclass.
> > You just want a slightly different behaviour.
> 
> Can I restate that as: You just want a slightly different behaviour but
> don't really care much how it's done so long as it's reasonably simple.

Right.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | [email protected] | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.