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