New to OO concepts - re-usability

[Ben Hutchings]

Chris Hanson <cmh at bDistributed.com> writes:

> In article <CgJk6.515$v77.66568 at newsread2.prod.itd.earthlink.net>,
> Chris Tavares <ctavares at develop.com> wrote:
> 
> > While the world is totally different (static vs. dynamic typing), the
> > concepts are in many ways the same. Studying the ideas behind the STL are
> > well worth doing for everyone I would think.
> 
> It's a great idea for learning what *not* to do.
> 
> The STL is horribly designed.  There's no hierarchy,

I think you mean it's not an OO design, and that's true.

There *are* common interfaces (random lookup, list-ops, front-ops,
stack-ops, iteration), but those interfaces aren't explicit so you
can't put off your choice of implementation to run-time - unless you
use wrappers.

> no real interchangeability in the container classes.

Some algorithms require different interfaces from others.  You can
interchange containers as long as you keep a clear idea of which
interfaces your algorithm(s) need and pick the right containers.  The
most common one is iteration, and almost all containers support that.

> And they force you to do all sorts of extra work (some of which just
> isn't feasible) to be able to store your objects in containers.

Storing polymorphic objects certainly seems to be too difficult, since
they have to be stored by reference and there is no ref-counting
smart-pointer class in the standard library (but there is
boost::shared_ptr).

> STL was designed by number crunchers with the broken assumption that
> programs are designed from the algorithm out and that efficiency is the
> absolute most important goal.  Software in the real world is designed
> from the business requirements out; this usually starts with a human
> interface and a set of user requirements, and efficiency is only
> measured compared to human use rather than the processor's maximum
> throughput.
<snip>

STL is not meant to do everything *for* the C++ programmer, but it is
meant to be used *by* every C++ programmer.  That's why it has to be
efficient and flexible, and not too abstract.  You can always write
wrapper classes on top of it that are more abstract but less flexible
or less efficient, but you could never write wrapper classes to make
an abstract container library more efficient!

-- 
Any opinions expressed are my own and not necessarily those of Roundpoint.