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

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

> > paradigms. More importantly, a well-architected OO system is typically far
> > more maintainable, and easier to adapt to changing requirements, than a
> > non-OO system.
>
> Aye. The fact that you can replace any part of the system by another part
> implementing the same interface without having to delve into the original
> source helps.

Where does the mistaken idea come from that this is proprietary to OO
systems?  It precedes at least C++ and Smalltalk, since structured
programming allows the same.  It's also quite possible once you've moved
beyond OO for modeling.

You'll have to sniff way back in the past to find the inventor of the
black box.

> An example of how an OO data model is important, I find, is creating
> proxies. Say you have your customer database full of customer objects,
> actually being an OO interface to an RDBMS or a full OODBMS or
> whatever. Then say that your company merges with another that uses a
> different model. You can write a new class implementing or
> inheriting "Customer" (depending on your language) that actually talks to
> the other database, and start instantiating customers from that database
> as well as yours and feeding them into the customer-processing code. If
> the customer-processing code assumed that the customers were XML in a
> filesystem, you'd have to do a lot of recoding or emulate a filesystem to
> do that...

You can, again, do this quite handily without messing with inheritance, as
long as your tools allow you.  OO tools largely restrict you to
inheritance for black-box substitution.  This is exactly one of the
problems I have with it.  I should be able to swap out the black boxes
through, say delegation, or by just merely following the protocol on the
outside of the box.

What you and Mike seem to be touting is common sense that needs no help
from OO, and indeed precedes OO, and will survive it.


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