Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ogicse!zephyr.ens.tek.com!tekchips!tekcrl!brucec From: brucec@phoebus.labs.tek.com (Bruce Cohen;;50-662;LP=A;) Newsgroups: comp.object Subject: Re: Redefining (used to be Void references) Message-ID: Date: 19 Nov 90 18:51:27 GMT References: <454@eiffel.UUCP> <1990Nov15.011702.25087@Neon.Stanford.EDU> <11113@pt.cs.cmu.edu> <1990Nov16.065609.15460@tukki.jyu.fi> <1990Nov17.174653.6291@ux1.cso.uiuc.edu> Sender: news@tekchips.LABS.TEK.COM Organization: Tektronix Inc. Lines: 66 In-reply-to: johnson@cs.uiuc.EDU's message of 17 Nov 90 17:46:53 GMT > In article <1990Nov16.065609.15460@tukki.jyu.fi>, sakkinen@tukki.jyu.fi (Markku Sakkinen) writes: > > In my opinion, inheriting only parts of superclass, say C, > into a subclass, say D, is a highly dubious idea even for this purpose. > One should rather have defined a fully-fledged class B containing > those parts first, then both C and D as subclasses of B. > It would be nice to have the kind of generalisation facilities > that Claus Pedersen suggested in his OOPSLA'89 paper: > that one could derive _super_classes approximately as easily > as existing languages allow us to derive _sub_classes. > and in article <1990Nov17.174653.6291@ux1.cso.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes: > > However, the kind of program resulting from prototyping this way should > never be mistaken for elegant programs. I rewrite code that results > from prototyping to make it elegant, and the rewriting often splits up > classes just the way Markku says. > I've recently started looking at dealing with this problem with what I call "behaviours", which are lightweight abstract classes which each incorporate the interface to one responsibility for its subclasses. Behaviours are completely disjoint in terms of interface and implementation; they may be composed into cooperating sets of behaviours, but they may not share parts of their interfaces or implementations. A given subclass will inherit from as many behavior superclasses as necessary for all of its responsibilities, in mixin style. No subclass may refuse to inherit a part of one of its superclasses (with careful design of the superclasses, there aren't any parts to object to; you either want the whole class or none of it). This style makes it easy to factor inheritance so that everything needed by a subclass is there, but the subclass doesn't get weighed down with things it doesn't need. It also makes it easy to rearrange inheritance without major surgery on a program; since the concrete subclasses largely consist of compositions of behaviours, most changes are a matter of altering the composition and removing or adding the private methods which connect the behaviors in the subclass. > I think that the conflict between getting something to work quickly and > making it elegant could be lessened with better programming environment > support. We need tools that would split up classes and derive new > super classes from exisiting classes. Tools like that would certainly be useful, especially in the case Ralph cites of trying to clean up a bloated prototype. I would like even more to have tools which allow me to build the original version in a more cleanly way, so I don't have to spend so much time cleaning up a program which already works. > Following the Scandianvian tradition, a program provides a model of > some system. When you find that you need to reuse just part of a class > then it means that your model was wrong. Instead of patching up the > code, you should fix your model. I favor making the unit of reuse very small. The smaller it is, the less of the reused object (class, code, or design) is likely to be unneeded in the reusing software. That's why I think the unit should be a part of a class; we just need to use tools which that convenient, and which don't encourage us to muddy the inheritance structure by ad hoc, and in a sense ex post facto, changes to the structure the is inherited. -- ------------------------------------------------------------------------ Speaker-to-managers, aka Bruce Cohen, Computer Research Lab email: brucec@tekchips.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077