Path: utzoo!attcan!uunet!image.soe.clarkson.edu!news
From: cline@cheetah.ece.clarkson.edu (Marshall Cline)
Newsgroups: comp.object
Subject: Should Shapes Display Themselves? [was: Display methods, pro or con...]
Message-ID: <CLINE.90Aug8130349@cheetah.ece.clarkson.edu>
Date: 8 Aug 90 17:07:14 GMT
References: <1681@dinl.mmc.UUCP> <25966@bellcore.bellcore.com>
Sender: news@sun.soe.clarkson.edu
Reply-To: cline@sun.soe.clarkson.edu (Marshall Cline)
Organization: (I don't speak for the) ECE Dept, Clarkson Univ, Potsdam, NY
Lines: 59
In-reply-to: sjs@roland.ctt.bellcore.com's message of 7 Aug 90 15:16:35 GMT

I just posted a `positive' follow-up to Stan Switzer's comments on policy
rather than mechanism.  However now I'd like to post a problem with Stan's
specific example of the Model-View-Controller (MVC) paradigm.

QUESTION: Should a `Shape' be able to `draw' itself?

The usual answer is ABSOLUTELY.  I have to totally agree, since adding a
new Shape (Hexagon, for example) only requires adding code rather than
changing existing code (as would be required if there were a global `draw'
function).  This is the usual ``don't operate on objects; instead enable
the object to provide services for you''.

However: what if I add a new terminal type?  Or what if I want a textual
`view' (using MVC terminology) rather than a graphical `view'.  The real
problem is: what if I want several views to coexist in the system at the
same time, so a Square is either `viewed' as a bunch of pixels, the name
"Square", or whatever, depending on which `view' it's being `drawn on'.

The best I've come up with is this:

	    GraphicalShape     TextualShape   <-- One per `view'
	                 \     /
	                  \   /
	                  Shape
	                 /  |  \
	                /   |   \
	               /    |    \
	         Square   Circle  Hexagon     <-- One per concrete Shape

	class GraphicalShape { public: void graphical_draw() = 0; };
	class TextualShape   { public: void textual_draw()   = 0; };
	class Shape : public GraphicalShape, public TextualShape { };

Adding an XYZView means adding XYZShape to the base class list of Shape,
and filling in the XYZ_draw() in each concrete Shape (Square, Circle, ...).
The advantage over simply adding another pure virtual XYZ_draw() to Shape
is that GraphicalView can have a list of GraphicalShape's but can't get at
a Shape's textual_draw().  (I'm not sure if that's a bug or a feature :-)

Unfortunately this scheme means `reopening' all the concrete Shapes
whenever a new `view' is added.  However at least adding a new Shape
doesn't involve changing existing code in each `view' class.

Pros?  Cons?

Some of these concerns *may* go away in untyped languages (Smalltalk etc)
but I'd like to see a reasonable solution in a [pseudo]strongly-typed OOPL
(C++ etc).

Marshall
--
==============================================================================
Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676
cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w
Voice: 315-268-3868 / Secretary: 315-268-6511 / FAX: 315-268-7600
Career search in progress; ECE faculty; research oriented; will send vita.
PS: If your company is interested in on-site C++/OOD training, drop me a line!
==============================================================================