Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!iuvax!rutgers!bellcore-2!bellcore!roland!sjs
From: sjs@roland.ctt.bellcore.com (Stan Switzer)
Newsgroups: comp.object
Subject: Display methods, pro or con...
Message-ID: <25966@bellcore.bellcore.com>
Date: 7 Aug 90 15:16:35 GMT
References: <1681@dinl.mmc.UUCP>
Sender: news@bellcore.bellcore.com
Reply-To: sjs@bellcore.com (Stan Switzer)
Organization: Bellcore
Lines: 82

Quite simply, the question is this: should objects be concerned with
their presentation?

Leaving aside objects which are explicitly intended as display
artifacts (windows, menus, etc.) and considering application domain
objects such as personnel files, tractors, and fishing boats, should
these objects be concerned with how they are displayed or should we
separate the objects (models) from views?

Pro:  It is a lot simpler to just put "printme" methods in objects, and
in any event a lot of objects exist primarily for presentation
purposes.  This argument is made in the Booch book (of which I have
rather mixed emotions).

Con:  A fishing boat is a fishing boat no matter whether I am using a
dumb terminal or an X terminal.  Furthermore, who is to say that there
is only one kind of view for an object.  Or even only one view of a
particular kind.

My opinion:  I am powerfully impressed with the Model-View-Controller
paradigm.  It seems to make a lot of sense to define "view" objects
which can be pointed at other objects to display them.  Views would
display objects according to their "type" (as opposed to their class).
There would be views for "tables" (classes which respond to the
messages of the "table" type).  Tables could be displayed in tabular
form, or as graphs, charts, etc.  It should be possible to have
multiple simultaneous views of a single object.  And heck, why limit
it to display?  There's no reason why dragging on the bars in a bar
chart shouldn't be able to manipulate the table it displays.

Not that it's always easy.  An interesting problem is described in
Cox's book: There is a graphical front-end to the "make" program (or
something like that.)  From a purely semantic point of view, the data
being displayed and manipulated is simply a partial ordered graph.  In
defining the objects representing the nodes, it really doesn't make
any sense to have an object representing a source file know anything
about where it is on the display, but on the other hand you really do
want (from the UI point of view) to be able to display the graph later
with the nodes in the same positions, even though this has nothing to
do with the basic notion of partial ordering.  Where do you keep this
"annotation" information?  The "Andrew" system, which takes pains to
separate "views" from "data" has an idea of "view data" (if I remember
correctly), which represents additional display information (color,
position, etc.) which is not present in the underlying object.  

We can even generalize this a bit.  Should an object's methods be
concerned with what it is *for* or simply with what it *is*.  Example:
personnel records.  We should certainly have methods which realize and
elaborate on the basic concept of personnel records, but should we
embed intelligence about company personnel policy in these objects?

Obviously, up to a point, form follows function, but once we have an
object (such as a personnel record) which was intended for a particular
function we now have a resource for future development.  For good or
ill, this data resource can be used in many ways.  Of course, the
general utility of the object is compromised if there is too much of
the original application's semantics built into the object.

Now these issues don't make much difference in-the-small, but I'm
thinking of large systems, either distributed systems based on O-O
concepts, or O-O DBMSs, or perhaps dozens of evolving, interrelated
applications.  Consider a distributed object-oriented application: it
might easily arise one application might have to keep information
(workforce management) "about" objects managed by another application
(personnel).  Do we consider this to be one big object (employee) whose
realization happens to be distributed (with part of the "employee"
being realized in the workforce management application and part in the
personnel application)?  Or, do we consider them separate objects which
happen to be closely related?

I propose that it makes a lot of sense, even at the highest levels of
design to keep separate the ideas of what an object *is* and what the
object is *for*.  It is going to be difficult to tease apart the
concepts of what we do *to* an object and what the object *does*.  Up
to a point--but where?--an object should be free of teleological
baggage.

So what do you think?  Are there any good papers discussing these
issues?  At this point, I'm mostly interested in the issue of display
methods, but I think the problem goes much deeper that that.

Stan Switzer  sjs@bellcore.com