Related articles |
---|
How should size of program grow with size of problem? jvn@fermi.clas.virginia.edu (Julian V. Noble) (1993-10-28) |
Re: How should size of program grow with size of problem? henry@zoo.toronto.edu (1993-11-03) |
interface reuse over code reuse sdm7g@elvis.med.virginia.edu (Steven D. Majewski) (1993-11-04) |
Re: interface reuse over code reuse throop@aurw44.aur.alcatel.com (1993-11-05) |
Re: interface reuse over code reuse carroll@hercules.cis.udel.edu (Mark C. Carroll) (1993-11-08) |
Re: interface reuse over code reuse pardo@cs.washington.edu (1993-11-09) |
Newsgroups: | comp.compilers |
From: | throop@aurw44.aur.alcatel.com |
Keywords: | OOP, design |
Organization: | Compilers Central |
References: | 93-10-136 93-11-032 |
Date: | Fri, 5 Nov 1993 18:09:00 GMT |
: From: henry@zoo.toronto.edu (Henry Spencer)
: [...] there are a significant number of people who think that once you
: strip away the OOH (Object-Oriented Hype), being able to reuse
: *interfaces* is much more important than being able to reuse code. If the
: interface is held constant, you can build up a library of different
: implementations of the underlying abstraction to satisfy different sets of
: tradeoffs.
True. And I agree rather strongly that issues of interface "ought" to be
separated from issues of implementation in the "type calculus", and any
related safety constraints, of a language.
But on the other hand, reusing implementation fragments is a powerful
mechanism for allowing one to quickly construct an implementation of a
rich interface. For instance, take that old ADT chestnut, the stack. The
interface might include things like "push", "pop", "top", queries like
"empty" and/or "size" and the like, and may include commonly used
accelerations like "nth" or "second" or "swap" or "dup".
The point is, being able to implement a new stack-interface-obeying
implementation by providing primitives, and allowing a base class to
invoke the primitives as virtual functions to compose higher-level
operations is, to me, what separates OO from, and gives it additional
leverage over, ADT. It's a notational convenience: I don't have to spell
out every method implementation, nor even declare where to get a canned
implementation for each method. I can just round up the usual suspects.
And when I realized that, it was the beginning of a beautiful friendship.
The leverage is an important one, I think. It allows one to quickly
satisfy a rich interface, even though the "reused" code may use "pop push"
to do "top" and "pop pop push push" to do "second", and so on. Then, if
the performance (or whatever property) of the reused code is an issue, it
can be specialized.
And here is the oddity this leads *me* to. I don't end up reusing
"tuned", "polished" code as the OOH so often promises. I reuse *UN*tuned,
"brute force" code. Which of course is hard to sell: "I'm using this
design technique because it will allow me to reuse rough, hacked-out
code." It sounds ludicrous. But I'm pretty convinced it is the Right
Thing, despite the seeming paradox. Because it *really* ammounts to "I'm
using this design technique because it will allow me to *avoid* *writing*
my Nth copy of loop-over-file, or draw-border-around-widget or whatever".
--
Wayne Throop throopw%sheol@concert.net
throop@aur.alcatel.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.