RE: Picking the Tools -- Marrying processing models to data model s

[Michael Brennan <Michael_Brennan@allegis.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. 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. There is also a rule of
thumb out there: usually the first time you design a class for reuse, you
don't quite get it right. It typically takes about 3 tries. That's just a
general rule of thumb, of course. The point is that developing something
that is reusable is more difficult than just writing a component to address
one very specific purpose. Typically flaws are encountered in the design as
you actually try to reuse it, and some refactoring of the component becomes
necessary. 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. More importantly, a well-architected OO system is typically far
more maintainable, and easier to adapt to changing requirements, than a
non-OO system.