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