|
 |
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
|
|
