From: rdm@uhura1.uucp (Rizwan D. Mithani)
Subject: Three approaches to designing OBJECTs
Followup-To: comp.object
Keywords: hierarchy, poymorphism, user-interface, reusability
Organization: SAI
Date: Thu, 21 Jan 1993 19:14:31 GMT



I am sure this has been faced by many of you.

We are developing a user-interface in C++, cenetered arround an OODBMS.

For better or for worse, all our persistent objects descend from 
the same class and form a hierarchy.  An application-independent
part of this hierarchy is show below

			PersistentObject (supplied by OODBMS vendor)
			      |
			    Entity      (data/functions added by us)
			    /    \
			EntityA  EntityB
			  /  \        |
			 /    \       |
		   EnityC    EntityD  EntityE
			        |
			     EntityF
			  
This hierarchy is expected to grow as and when new modules are 
added to the system.

Further, there are various Views into the sytem, for e.g. a graphic
view, a textual view of the attributes of an entity, etc.  Thus, let
me throw in two potential object views  -
GraphicWindow provides a graphical view of a collection
of arbitrary entities, while Panel provides a display/edit 
capability for the attributes of an arbitrary entity.  

The way we see it, there are 3 approaches to building a solution.

Approach 1:
-----------

Treat Entitys as data-stores, with Get/Set operations for its
attributes.

Define a GraphicWindowManager class, whose responsibility is to 
query any Entity that needs to be drawn for the value/state of
appropriate attributes and do the drawing itself.

Define a PanelManager class, whose responsibility is to query
the Entity to display its attributes, and set the values of the
attributes when they are edited. Further, the PanelManager would
be responsible for tracking multiple panels. Note, there will
exist a class called Panel to support this.


Approach 2:
-----------

Let Entitys do the work.

Define polymorphic/virtual functions DisplayPanel and Draw within
the Entity hierarchy.  We still need a GraphicsWindowManager who
just tells the entity to Draw itself, passsing the function any
required parameters.  Now we get rid of the PanelManager, and 
anybody wishing to display a panel sends a DisplayPanel message
to the Entity in question, and this function would construct
the Panel and display it; a complementry function would take
care of storing the data away for the entity, when the user indicates
to apply his changes.

Note, one cannot store any transient state information in an 
Entity to allow performing its functions, because the entities
are persistent, and upon closing the application these state 
variables have no semantics, but would stick around for the
lifetime of the database.


Approach 3:
-----------

Define a corresponding View hierachy for each view into the system

Thus define a hierarchy for PanelA thru' PanelF descending from
Panel, and a hierarchy for GraphicA thru' GraphicF descnding form
Graphic.  When a Panel needs to be displayed for EntityA, simply
construct PanelA, which would of course have EntityA associated 
with it; PanelA object would also be responsible for storing the
values away.  When EntityB needs to be drawn, construct GraphicB
associated with EntityB, and send GraphicB a Draw message, along
with required parameters.


Question?
---------

Which of these 3 approaches is best?  
Have any of you used an approach (or a mixture) and learnt any
lessons which you would like to share?
What are the pros and cons of each approach as it relates to 
extensibility, maintainability, resusability, testing, proting, 
and using them within C++ ?



-- 
Rizwan Mithani ( rdm%uhura1@uunet.uu.net )
*** The opinions expressed above are mine. ***
*** They do not reflect the views of SAI.  ***