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

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

> > From: Uche Ogbuji [mailto:uche.ogbuji@fourthought.com]
> > [...]
> > Reusability is one of the biggest lies of OO.  I personally think that
> > code reusability is the philosopher's stone: it would be a source of
> > never-ending value, but there is the small problem that it
> > doesn't exist.
> > There is nothing special about OO that makes code reuse
> > magically easier.
> > The strange theory that inheritance is the key to object
> > re-use is one of
> > the reasons I've heard for the insistence of some component models on
> > making inheritance part of large-granularity interfaces.  This doesn't
> > lend any magic reusability to components than it does to
> > class libraries.
>
> OO does not make reuse magically happen. However, in the hands of a skilled
> developer who knows how to design with reuse in mind, OO is a much more
> effective tool for supporting reuse than alternative approaches.

Such as?  I've mentioned some modeling facilities not native to OO.  You
say that OO has better propensity to reuse?  What makes you think so?

> Designing with reuse in mind is challenging, though, and many developers
> never really get the hang of it. That's not the fault of OO.

No, it's the fault of unrealistic expectations about how the real world
changes around fine-grained design.  OO is no more help than hindrance.
Well, to be sure, it can be quite a hindrance when it's not suited to the
task at hand in the first place.

> The point is that developing something that is reusable is more difficult
> than just writing a component to address one very specific purpose.

Usually it's just wasted exercise.  I've worked in organizations with
top-notch OO developers, top-notch tools and metadata facilities.  I
don't dismiss code reuse without experience.

> It takes time to get it right. Once you have it right, though,
> the OO model is far more conducive to effect reuse than other development
> paradigms.

Again, such as?  What are these "other development paradigms"?  Perhaps
you'll find no argument.

> More importantly, a well-architected OO system is typically far
> more maintainable, and easier to adapt to changing requirements, than a
> non-OO system.

This depends on your definition of "system".  If you mean "code module",
you're right.  If you mean "large-scale application", you're wrong.

There was a time, just three years ago when I would have made as
categorical statement as you do.  After all, I'd built my career on C++
"done right".  I think I've had very good reason to change my mind.


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