Path: utzoo!utgpu!watmath!clyde!att!rutgers!cs.utexas.edu!pp!cadillac!vaughan From: vaughan@cadillac.CAD.MCC.COM (Paul Vaughan) Newsgroups: comp.lang.c++ Subject: Re: OOP languages and software reuse Summary: An Example Message-ID: <618@cadillac.CAD.MCC.COM> Date: 2 Dec 88 17:29:11 GMT References: <1250001@hpcllca.HP.COM> <612@cadillac.CAD.MCC.COM> <10121@watdragon.waterloo.edu> Organization: MCC VLSI-CAD Program, Austin, TX Lines: 43 > How does this help the incrementality problem? In what way can > you incrementally modify a program which you could not before? Here is an example. Suppose you have an interactive graphics editor that you want to use to edit simulation models. Further suppose that the graphics editor defines a class to represent sheets (drawing areas, empty pages), and defines that when a user puts a new graphic object onto the sheet, the message add-object will be sent to the sheet. Knowing this, it is possible to define a class based on the sheet class which has an "after" method for add-object which also updates the simulation data structures. I've managed to do this sort of thing a couple of times now and this leads me to believe that a well designed object-oriented graphics editor could be a standard component for alot of applications. It's incremental in that the designer of the graphics editor need not know very much about how the editor will be used. Unfortunately, he does have to guess about what information client applications will need to know about things that go on in the editor. Of course, it is possible to define explicit program hooks in an ordinary language and to document these. The object oriented approach makes it more natural and has one more advantage. Even when the program designer hasn't anticipated a need, it is often possible to examine the source and discover what messages are called. At this point it is possible to define "after" methods for these methods do what needs to be done, without modifying the original program. (Of course, relying on undocumented features is not an especially good idea, but it can get the job done.) > ie. I have a pre-existing class STRING (built by someone else), > which I am not allowed to modify. Then I cannot sort it, unless > the designer anticipated my need and caused STRING to inherit from > SORTABLE. Coming from a Lisp background, my answer is that STRINGs are obviously derived from SEQUENCEs, which are sortable. But I see your point. However, you can still sort the STRING as long as STRING provides some way of accessing and setting the elements in order. Any design of STRING which doesn't let you do that is deficient. -- Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639 Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan