Has anyone ever actually found an OO library to be more "reusable" than 
the same thing would be (say) organized procedurally? Has anyone made 
significant reuse of classes by overriding methods the original authors 
hadn't intended to be overridable? I'm not saying OO is a bad way of 
organizing something that has "objects" in it (like a windowing system 
or a simulation), but that it doesn't automatically lead to greater 
"reusability" as so many promised when it first got popular. (I count 
"reuse" as the ability to take code already written and use it in ways 
not anticipated when it was written.)

I think macro processors and standards lead to much greater reusability. 
The C preprocessor (m4 et al) is used in lots of other places. The IEEE 
floating point standard and the ANSI standards and regular expression 
definitions and RFCs are highly reusable (look how much stuff goes over 
HTTP that shouldn't). Even "components" (a la .NET or COM) are more 
reusable at the programming language level than OO tends to be nowadays 
(altho even there it's difficult to use a particular component in 
unforseen ways). Filter programs are very reusable for things the 
original authors never thought of. Virtual machines seem to get a lot of 
unexpected reuse - Ruby ported to the JVM, Bartok compiling .NET 
assembler language into raw native code, etc. Systems where you plumb 
bits together (pipes and filters, plug-in architectures, message-passing 
paradigms) seem to lead to more reuse than expected.

But particular OO libraries are IME limited to doing exactly what they 
were designed to do, without really being any more extensible than a 
procedural language with carefully crafted callbacks. For the most part, 
it seems OO has exactly one benefit, which is that you can add a 
subclass that follows the same contract as the sibling classes, and you 
don't need to change the parent class or callers to deal with this. But 
this isn't "reuse", it's just "convenient callback specification."

(I remember many years ago realizing there was no routine in Smalltalk 
that took a point X and a line and told you what the closest point on 
that line to X was. So I figured out the geometry and algebra, wrote the 
routine, and thought "well, that was a PITA, but it's OO, so at least 
I'll never have to do it again."  How naive I was.)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message
news:48ac49b3$1@news.povray.org...

> Has anyone ever actually found an OO library to be more "reusable" than
> the same thing would be (say) organized procedurally? Has anyone made
> significant reuse of classes by overriding methods the original authors
> hadn't intended to be overridable? I'm not saying OO is a bad way of
> organizing something that has "objects" in it (like a windowing system
> or a simulation), but that it doesn't automatically lead to greater
> "reusability" as so many promised when it first got popular. (I count
> "reuse" as the ability to take code already written and use it in ways
> not anticipated when it was written.)

I tend to agree with you. A procedural library with proper standards and
documentation is much easier to use *and* extend. Problem with OO is just
what you mention, "anticipation". If the authord of an OO library did not
anticipate a usage pattern that you wish to employ, it's
unusable/unextendable at worst, and inefficient at best.

A great majority of the time, I write procedural libraries. I still use and
extend libraries I've written 15 years ago. For a new project, I write OO
wrappers around those libraries. I rarely, if ever, re-use those objects
outside that particular project.

OOP is only an improvement over using global variables in procedural
programming. It's *not* an improvement over procedural programming. If one
can wrap everything in procedures, that's the ideal, if you ask me.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> (I count 
> "reuse" as the ability to take code already written and use it in ways 
> not anticipated when it was written.)

  Maybe your definition of "reusability" is different than what it's really
meant.

  IMO a reusable component is one which you can take out of the original
program it was developed for, and use it (usually for the same purpose)
in a different program.

  Of course a generic library is reusable by definition (because it has
not been developed for a specific program, but to be reusable in all kinds
of programs). However, what OOP advertises is that, when you are developing
a program, if you design your objects properly, there's a high chance that
those objects will not be completely tied to that specific program, but can
be reused in other programs as well.

  What does OOP in particular bring to the whole reusability concept?
It brings the concepts of encapsulation, abstraction and (minimal)
interfaces. When properly implemented, these concepts aid in making a
module reusable (ie. not tied to a specific program).

  That doesn't mean other programming paradigms wouldn't support those
same concepts. It's just that OOP has been designed with those concepts
as the main starting points.

  (Whether the OOP paradigm has completely succeeded in this goal is open
to debate, but IMO it has succeeded pretty well, even if not perfectly.)

-- 
                                                          - Warp

Post a reply to this message

somebody <x### [at] ycom> wrote:
> I tend to agree with you. A procedural library with proper standards and
> documentation is much easier to use *and* extend. Problem with OO is just
> what you mention, "anticipation". If the authord of an OO library did not
> anticipate a usage pattern that you wish to employ, it's
> unusable/unextendable at worst, and inefficient at best.

  Uh. Basically you are saying "a well-designed procedural library is much
better than a badly-designed OO library". Well, duh.

  Obviously we should compare well-designed procedural libraries with
well-designed OO libraries.

> OOP is only an improvement over using global variables in procedural
> programming. It's *not* an improvement over procedural programming. If one
> can wrap everything in procedures, that's the ideal, if you ask me.

  Exactly how would you implement, for example, a linked list or a binary
tree without using any objects?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Uh. Basically you are saying "a well-designed procedural library is much
> better than a badly-designed OO library". Well, duh.

Well, what *I* was saying is that a well-designed OO library isn't 
generally better (in the reusability sense) than a well-designed 
procedural library. Especially when you don't have object-type data 
you're manipulating in the first place. Sure, an OO GUI library is 
likely to be better than a procedural GUI library. But if the thing 
you're making a library of doesn't inherently have a heirarchical 
inheritance kind of structure, it's been my experience it doesn't help 
to make it OO. (E.g., it doesn't help to make a logging library OO, or a 
text processing library OO, or etc.)

For example, I haven't found any OO language where I could (for example) 
rip out the email/MIME handling code and use it to implement an NNTP 
client, unless the email/MIME handling code was specifically designed to 
be used in a second project anyway. It takes as much discipline to make 
reusable OO code as it does to make reusable procedural code, but more 
discipline than it takes to make reusable 
concurrency-oriented-programming code or stand-alone whole-program code.

>   Exactly how would you implement, for example, a linked list or a binary
> tree without using any objects?

Because, you know, nobody ever implemented a linked list or a binary 
tree in FORTRAN, or C, or ... :-)

 >   IMO a reusable component is one which you can take out of the original
 > program it was developed for, and use it (usually for the same purpose)
 > in a different program.

Yep. That's what I mean.

 > those objects will not be completely tied to that specific program, 
but can
 > be reused in other programs as well.

I've found that not to be the case. That's kind of what I meant. It 
takes a lot of design-fu to be able to do that naturally without 
intentionally sitting down to make that happen.

 >   That doesn't mean other programming paradigms wouldn't support those
 > same concepts. It's just that OOP has been designed with those concepts
 > as the main starting points.

I believe it has failed. I don't see OO classes that aren't designed as 
stand-alone from the start as being any less decoupled from their 
environment than procedural languages similarly designed. The idea that 
OO automatically leads to self-contained classes that can be (a) reused 
elsewhere and/or (b) extended via inheritance in unanticipated ways is 
just wrong.

Because I've done stuff like that. I've tried to (for example) take a 
credit-card-clearing class from one PHP program and use it as the backup 
when the credit-card-clearing class from the other PHP program fails, 
and it just doesn't work. Things rely on particular logging mechanisms, 
particular configuration system, particular error handling strategies. 
There's too much expectation on the environment, unless you diligently 
avoid it from the start. (Of course, the same is usually true of 
procedural code, but my contention isn't that OO is *worse*.)

That has been my experience, at least.

 >   (Whether the OOP paradigm has completely succeeded in this goal is open
 > to debate, but IMO it has succeeded pretty well, even if not perfectly.)

Well, yeah, that's kind of what I was debating. ;-)  In any case, I 
think it's more that the memory management of OO languages has helped 
the reusability more than the actual "OO-ness", or class information 
hiding stuff.  I don't think it's the "if you want to change something, 
inherit and override" that does it as much as it is the "you don't have 
to dick with half a dozen memory allocators to make stuff work."

And I think there are a lot of programming techniques that lead to 
*more* reusability than OO does. OO classes are too small and the 
borders between them too wide and (in general) poorly specified to 
achieve the aims people claimed for them.

Has anyone here actually pulled classes out of some program that wasn't 
intended to be pulled apart, and used them without major reworking?

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
>  >   That doesn't mean other programming paradigms wouldn't support those
>  > same concepts. It's just that OOP has been designed with those concepts
>  > as the main starting points.

> I believe it has failed. I don't see OO classes that aren't designed as 
> stand-alone from the start as being any less decoupled from their 
> environment than procedural languages similarly designed.

  You have got it backwards. It's not like OOP would somehow magically
make any code you write more reusable. The actual point is that if you
want to make reusable code, OOP makes it *easier* than many other, simpler
paradigms. This is because OOP offers strong tools for this exact purpose
(such as abstraction and encapsulation).

  Let me propose an allegory for this: Just because you own a set of
kitchen utensil doesn't make you a better cook. However, if you are a
good cook, the kitchen utensil set will make it much easier for you to
prepare a meal. A set of carpenter tools, however, would be a rather poor
choice for preparing a meal, even though carpenter tools are good for
other, completely different tasks.

> The idea that 
> OO automatically leads to self-contained classes that can be (a) reused 
> elsewhere and/or (b) extended via inheritance in unanticipated ways is 
> just wrong.

  True. And this shows that you have misunderstood what OOP is. It's a
set of tools, not magic.

> Because I've done stuff like that. I've tried to (for example) take a 
> credit-card-clearing class from one PHP program and use it as the backup 
> when the credit-card-clearing class from the other PHP program fails, 
> and it just doesn't work.

  A certain programming paradigm will not make you a better programmer.
You can write crappy programs in any language.

>  >   (Whether the OOP paradigm has completely succeeded in this goal is open
>  > to debate, but IMO it has succeeded pretty well, even if not perfectly.)

> Well, yeah, that's kind of what I was debating. ;-)  In any case, I 
> think it's more that the memory management of OO languages has helped 
> the reusability more than the actual "OO-ness", or class information 
> hiding stuff.  I don't think it's the "if you want to change something, 
> inherit and override" that does it as much as it is the "you don't have 
> to dick with half a dozen memory allocators to make stuff work."

  I really can't see how memory management has anything to do with
reusability. Just because something has automatic memory management
doesn't make the code any more (or less) reusable. A crappy program
is still a crappy program even if it doesn't leak memory.

  The one thing which OOP has contributed greatly to reusable programming
is the concept of modules. (Not really an "invention" of the OOP paradigm,
but it's the paradigm which made it available to the masses.)

  Even the most OO paradigm hating coder cannot deny the usefulness of
modules, which are the basic building blocks of OOP languages. (And
for those who don't know what a module is, many OOP languages call it
"class".)

> Has anyone here actually pulled classes out of some program that wasn't 
> intended to be pulled apart, and used them without major reworking?

  You have still got it backwards.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> want to make reusable code, OOP makes it *easier* than many other, simpler
> paradigms. 

Hmmmm. Again, I'm not sure I agree.

> (such as abstraction and encapsulation).

But there are many other paradigms that do this far *far* better. 
Message-passing concurrency. UNIX-like filters. Etc.

I don't think OO goes far enough.

>> The idea that 
>> OO automatically leads to self-contained classes that can be (a) reused 
>> elsewhere and/or (b) extended via inheritance in unanticipated ways is 
>> just wrong.
> 
>   True. And this shows that you have misunderstood what OOP is. It's a
> set of tools, not magic.

Um, yes, I know, thanks.  But in the early days, it was claimed that 
making something OO would make it easier to reuse in new projects. I've 
just never found that to be the case. (See the whole "software ICs" stuff.)

>   I really can't see how memory management has anything to do with
> reusability. Just because something has automatic memory management
> doesn't make the code any more (or less) reusable. 

Memory management makes things easier because you can treat objects as 
entities. If the object comes with its own mechanism for deallocating 
the memory when it's no longer needed, then your library doesn't have to 
implement that and your callers don't have to enforce it.

If it's automated, all the better.

Or are you telling me it's not easier to write libraries in C++ than in 
C because of the destructors?  Would C++ be that much easier than C if 
you didn't have destructors?

Having memory management built in to some degree isolates you from 
having to know what's inside the object to that degree. You don't have 
to say "when you're done with this, call DisposeMyThing(mything) to free 
all the memory allocated."  If you actually have something like GC, you 
can say "and don't worry if I've formerly returned a pointer to 
something inside, or if you passed me a pointer to something outside."

>   The one thing which OOP has contributed greatly to reusable programming
> is the concept of modules. (Not really an "invention" of the OOP paradigm,
> but it's the paradigm which made it available to the masses.)

The idea of modules was around long before OOP. :-) They were called 
"libraries".

>   Even the most OO paradigm hating coder cannot deny the usefulness of
> modules, which are the basic building blocks of OOP languages. (And
> for those who don't know what a module is, many OOP languages call it
> "class".)

Except the problem I think is that most OOP modules are much larger than 
  a class. And you probably still have trouble retargetting them to a 
*slightly* different purpose.

>> Has anyone here actually pulled classes out of some program that wasn't 
>> intended to be pulled apart, and used them without major reworking?
> 
>   You have still got it backwards.

Perhaps. I think you're trying to say that writing reusable OOP is 
easier than writing reusable procedural. I'll grant that might be the case.

I'll argue that other paradigms are even easier to write reusable in. 
I'll also argue that non-reusable OOP isn't any easier to make reusable 
than non-reusable procedural code, which I think is also what many early 
advocates of OOP were suggesting.  "Just subclass someone else's class, 
and change the routines you need changed, and viola!"

I'm probably talking about more rabid advocates of OO-reuse than you 
are. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Um, yes, I know, thanks.  But in the early days, it was claimed that 
> making something OO would make it easier to reuse in new projects.

  Obviously we should assume the word "properly" in there.

  One could say that if you write a class which is *not* reusable, then
your OO design is bad.

> >   I really can't see how memory management has anything to do with
> > reusability. Just because something has automatic memory management
> > doesn't make the code any more (or less) reusable. 

> Memory management makes things easier because you can treat objects as 
> entities. If the object comes with its own mechanism for deallocating 
> the memory when it's no longer needed, then your library doesn't have to 
> implement that and your callers don't have to enforce it.

  Still can't see what this has to do with reusability. Reusability is
a question of design, not a question of memory management.

> Or are you telling me it's not easier to write libraries in C++ than in 
> C because of the destructors?  Would C++ be that much easier than C if 
> you didn't have destructors?

  Still can't see the connection to reusability.

  Perhaps you are confusing "reusable" with "easy to use"? Different things.

> Having memory management built in to some degree isolates you from 
> having to know what's inside the object to that degree. You don't have 
> to say "when you're done with this, call DisposeMyThing(mything) to free 
> all the memory allocated."  If you actually have something like GC, you 
> can say "and don't worry if I've formerly returned a pointer to 
> something inside, or if you passed me a pointer to something outside."

  Still related to ease of use rather than reusability.

> >   The one thing which OOP has contributed greatly to reusable programming
> > is the concept of modules. (Not really an "invention" of the OOP paradigm,
> > but it's the paradigm which made it available to the masses.)

> The idea of modules was around long before OOP. :-)

  Didn't you read what I wrote in parentheses?

> They were called "libraries".

  When I say "module" I'm referring to a much more concrete entity than
a generic "library". I'm talking about modules as per the modular programming
paradigm.

  Some people call C header+source file pairs "modules", but that's not
the kind of module I'm talking about. That has little to do with the modular
programming paradigm.

> I'll argue that other paradigms are even easier to write reusable in. 

  I'll believe it when I see it.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   One could say that if you write a class which is *not* reusable, then
> your OO design is bad.

But you could say that about a library/collection of general functions 
in a procedural language, too. If your higher-level OO class depends on 
a lot of lower level classes having the proper semantics and calls, 
you're not going to be able to reuse it.  If your MIME parser depends on 
certain memory allocation mechanisms, regular expression libraries, and 
so on, it's going to be difficult to reuse without bringing in the 
entire stack.

>   Still can't see what this has to do with reusability. Reusability is
> a question of design, not a question of memory management.

You don't have to design the memory management. :-)  And, more 
importantly, the memory management doesn't conflict with someone else's 
memory management.

>   Perhaps you are confusing "reusable" with "easy to use"? Different things.

Nope.

>   Still related to ease of use rather than reusability.

You have to spend less time tracking what's inside the class if the 
memory management (well, really, resource management) is done 
"properly". You don't have to worry if (for example) object A you passed 
to object B to initialize B is still being referenced after you've 
finished with B. E.g., if you pass a bitmap to a window for drawing, 
when can you throw away the bitmap? Does the window object copy the 
bitmap or just hold a reference to it? If you actually have to say, then 
you've exposed implementation details of your class, and of the bitmap 
class (which now might need a "clone me" operator). This gets even more 
obvious when you start having things like a open-file-handle used by a 
certificate used by an encryption-in-progress used by an SSL-link used 
by a socket used by an HTTPS connection used by a network-rpc used by 
.... When is it safe to close the file handle if you're the one that 
opened it?

If the memory management is more automated (and here I count C++ as 
"more automated"), then your window class can work with bitmaps that 
don't have the "clone me" method implemented (because, perhaps, they're 
too big to fit in RAM all at once anyway). When the caller closes the 
bitmap *and* the window, the memory and/or file handle goes away.

This is kind of exactly the sort of thing you complain about with 
finalizers versus destructors all the time. I'm kind of surprised you're 
now disagreeing with me.

>> The idea of modules was around long before OOP. :-)
>   Didn't you read what I wrote in parentheses?

Of course. But if it's modules that make something reusable and not 
objects, then that's just supporting my point.

>> They were called "libraries".
> 
>   When I say "module" I'm referring to a much more concrete entity than
> a generic "library". I'm talking about modules as per the modular programming
> paradigm.

I know.  In practice, a "library" is also a "module" in many ways, 
especially if designed to be reusable.  By which I mean a library 
designed to do one specific thing, such as parse XML or so. Yes?

>   Some people call C header+source file pairs "modules", but that's not
> the kind of module I'm talking about. That has little to do with the modular
> programming paradigm.

Hmmmm... I suspect you'd have to describe to me what you think "modular 
programing paradigm" means before we could talk meaningfully about that.

>> I'll argue that other paradigms are even easier to write reusable in. 
>   I'll believe it when I see it.

How many people reuse the work that went into Apache in their own 
programs? Half the web sites on the internet?  :-) How many CLI source 
code control systems on UNIX use a linked-in editor rather than invoking 
$EDITOR as a separate program?  How many link in database engines rather 
than having them running as a separate executable?

Obviously packaging up your code as a separate executable file makes it 
easier to use from other programs in some ways than does packaging it as 
an object-oriented class library.  Harder to reuse in *my* sense of the 
word, perhaps.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:

> (I count 
> "reuse" as the ability to take code already written and use it in ways 
> not anticipated when it was written.)

Isn't that "extensibility", not "reusability"? You want to *extend* 
existing software to do something it wasn't designed to do.

> But particular OO libraries are IME limited to doing exactly what they 
> were designed to do, without really being any more extensible than a 
> procedural language with carefully crafted callbacks.

You're still talking about "extensible", not "reusable".

In a classic procedural language like, say, Pascal, it is basically 
impossible to write a reusable sorting algorithm. That's because Pascal 
is a monomorphic language, so it forces you to write SortIntArray(), 
SortRealArray(), SortStringArray(), SortIntList(), SortRealList(), 
SortStringList(), SortIntDList(), SortRealDList()... are you getting 
bored yet?

With any half-decent OO language, this problem immediately goes away. 
You can now write a sorting algorithm once for each container type (or 
even once overall if you desire, but that's probably less efficient) and 
you're done. This one sorting algorithm can then be reused anywhere you 
need to sort data.

These days OOP isn't the only paradigm that actually offers this 
benefit, but the benefit is real none the less.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message