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