fischer@iesd.auc.dk (Lars P. Fischer) (10/11/89)
In article <130023@gore.com> jacob@gore.com (Jacob Gore) writes: >Single inheritance makes it unnecessarily difficult to modify the behavior >of non-leaf classes of the AppKit. For example, suppose I make a subclass >of Window, called MyWindow, which changes the behavior of one of the >methods. Oh, let's say, the way the miniwindow's title is computed. >Now, all I have to do is use instances of MyWindow instead of Window, and I >get the new behavior. > >But... Panel is subclassed from Window, not MyWindow, so I have to go in >and add or override those same methods in MyPanel. With two copies of the >same code, sitting in two different classes, it's harder to maintain it. >It would have been so nice to be able to do: > @interface MyPanel: Panel, MyWindow { ... } The way to do this would be to create a class, ComputeableName, witch is then added to both Panel and Window using MI. ComputeableName is an example of what is called a "mix-in", isolating an option that can be added to other classes. See Bobrow&Stefik (OO Programming: Themes and Variations, AI magazine, 1985) for a good treatment of this (and many other topics)). Using MI takes a good deal of care, but using "mix-ins" on predefined classes is manageable and also makes some sense in terms of "models of the real world". And, uhh, this really does not belong in comp.sys.next. Follow up to comp.object (no comp.lang.obj-c, yet). /Lars -- Copyright 1989 Lars Fischer; you can redistribute only if your recipients can. Lars Fischer, fischer@iesd.auc.dk, {...}!mcvax!iesd!fischer Department of Computer Science, University of Aalborg, DENMARK. "That makes 100 errors; please try again" --TeX