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