johnson@p.cs.uiuc.edu (03/28/89)
I'll comment on several articles. >Organization: U of Cambridge Comp Lab, UK >Senders: Peter Dickman & Stephen Hailes <pwd@uk.ac.cam.cl> > >In our opinion, inheritance is likely to compound the problems inherent in >maintaining large systems, even though it superficially makes this easier >in the short term. > Actually, inheritance does not help all that much in the short term, but its main advantages come with large systems developed over a long period of time. It takes a long time to find good abstract classes, and they are usually discovered by generalizing a number of concrete ones. If you aren't careful, inheritance just ends up being the edit history of a program. You have to reorganize your class hierarchy to prevent this from happening. In the process you discover new abstractions. awn@computing-maths.cardiff.ac.uk (Andrew) responds with: >This is interesting, has anyone done a comparitive study of Object >Oriented and other programming methodologies for designing large >systems? What advantages do OO languages bring to the process? Nobody does comparative studies of anything for designing large systems. It is too expensive. Nobody wants to spend a few million dollars to build a second version of a system just to see which method works better. >Superficially at least, OO seems to be little more than a syntactic nicety >which can reduce the amount of typing you need to do when defining a system. >Closer study reveals that OO is a nice way of organising the reusability of >code and other information and so might reduce the time taken to 'evolve' >an existing system. Yes, the main advantage of OOP is that it makes it possible to design elegant systems. You can do bad programming in any language, but a good object-oriented design can make it really easy to understand what is going on. Abstract classes can describe the interfaces between different kinds of components. >However I remain unconvinced >that for large systems (say 200 classes or more) OO will not add to >the complexity of the problem. The inheritance mechanism with all >its wondeful 'rename' and 'redefine' and 'local' and 'public' is >confusing, even to someone who knows what is going on and will I'm sure >create an inertia of its own to the process of implementing systems. A highly polished set of classes will not have 'rename' and 'redefine'. They are what you use to achieve unplanned reuse. Once you have a working system then you should restructure it to remove the kludges you built while you were prototyping.
ech@pegasus.ATT.COM (Edward C Horvath) (04/03/89)
From article <118100001@p.cs.uiuc.edu>, by johnson@p.cs.uiuc.edu: > A highly polished set of classes will not have 'rename' and 'redefine'. > They are what you use to achieve unplanned reuse. Once you have a working > system then you should restructure it to remove the kludges you built > while you were prototyping. I must disagree: you might as well say that there's no need for deferred features. Overriding the "draw" feature of a subclass of "graphical object" is the classic example of a function that REQUIRES redefine. A true sub-class may also save by using rename as well, to provide access to the redefined parent feature. Rename has other uses as well, mainly providing features with more "natural" names in the new derived class's context. Disambiguating feature-name collisions is essential in any case; you might argue that name collisions are in the nature of a "kludge," but again I must disagree: "create" "print" and many other "generic" features shouldn't need to be uniquely named across the entire class space! Better to name a spade a spade, and distinguish the two only in classes that both dig holes and play bridge. That's not to say that, having finished the first draft, there are never improvements to be made; still, your implicit assumptions only apply to "toy" projects. It's unwarranted to assume that one can blithely modify the interfaces of all the classes one uses. Even if I do have such access, if the class library is shared with others, I can't just arbitrarily rename features (unless I want to maintain EVERYBODY's code -- no thank you!). Finally, rare indeed is the development project where one has time in the schedule to go back and "remove the kludges" one introduced. I'd be more likely to go back to rename inherited features to be more natural, or redefine features that didn't QUITE match up with the inherited ones. =Ned Horvath=