home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / object / 4984 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  3.9 KB
  1. Xref: sparky comp.object:4984 comp.lang.c++:19707
  2. Newsgroups: comp.object,comp.lang.c++
  3. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!menudo.uh.edu!lobster!mondy!uhura1!rdm
  4. From: rdm@uhura1.uucp (Rizwan D. Mithani)
  5. Subject: Three approaches to designing OBJECTs
  6. Message-ID: <1993Jan21.191431.11321@uhura1.uucp>
  7. Followup-To: comp.object
  8. Keywords: hierarchy, poymorphism, user-interface, reusability
  9. Organization: SAI
  10. Date: Thu, 21 Jan 1993 19:14:31 GMT
  11. Lines: 103
  12.  
  13.  
  14.  
  15. I am sure this has been faced by many of you.
  16.  
  17. We are developing a user-interface in C++, cenetered arround an OODBMS.
  18.  
  19. For better or for worse, all our persistent objects descend from 
  20. the same class and form a hierarchy.  An application-independent
  21. part of this hierarchy is show below
  22.  
  23.             PersistentObject (supplied by OODBMS vendor)
  24.                   |
  25.                 Entity      (data/functions added by us)
  26.                 /    \
  27.             EntityA  EntityB
  28.               /  \        |
  29.              /    \       |
  30.            EnityC    EntityD  EntityE
  31.                     |
  32.                  EntityF
  33.               
  34. This hierarchy is expected to grow as and when new modules are 
  35. added to the system.
  36.  
  37. Further, there are various Views into the sytem, for e.g. a graphic
  38. view, a textual view of the attributes of an entity, etc.  Thus, let
  39. me throw in two potential object views  -
  40. GraphicWindow provides a graphical view of a collection
  41. of arbitrary entities, while Panel provides a display/edit 
  42. capability for the attributes of an arbitrary entity.  
  43.  
  44. The way we see it, there are 3 approaches to building a solution.
  45.  
  46. Approach 1:
  47. -----------
  48.  
  49. Treat Entitys as data-stores, with Get/Set operations for its
  50. attributes.
  51.  
  52. Define a GraphicWindowManager class, whose responsibility is to 
  53. query any Entity that needs to be drawn for the value/state of
  54. appropriate attributes and do the drawing itself.
  55.  
  56. Define a PanelManager class, whose responsibility is to query
  57. the Entity to display its attributes, and set the values of the
  58. attributes when they are edited. Further, the PanelManager would
  59. be responsible for tracking multiple panels. Note, there will
  60. exist a class called Panel to support this.
  61.  
  62.  
  63. Approach 2:
  64. -----------
  65.  
  66. Let Entitys do the work.
  67.  
  68. Define polymorphic/virtual functions DisplayPanel and Draw within
  69. the Entity hierarchy.  We still need a GraphicsWindowManager who
  70. just tells the entity to Draw itself, passsing the function any
  71. required parameters.  Now we get rid of the PanelManager, and 
  72. anybody wishing to display a panel sends a DisplayPanel message
  73. to the Entity in question, and this function would construct
  74. the Panel and display it; a complementry function would take
  75. care of storing the data away for the entity, when the user indicates
  76. to apply his changes.
  77.  
  78. Note, one cannot store any transient state information in an 
  79. Entity to allow performing its functions, because the entities
  80. are persistent, and upon closing the application these state 
  81. variables have no semantics, but would stick around for the
  82. lifetime of the database.
  83.  
  84.  
  85. Approach 3:
  86. -----------
  87.  
  88. Define a corresponding View hierachy for each view into the system
  89.  
  90. Thus define a hierarchy for PanelA thru' PanelF descending from
  91. Panel, and a hierarchy for GraphicA thru' GraphicF descnding form
  92. Graphic.  When a Panel needs to be displayed for EntityA, simply
  93. construct PanelA, which would of course have EntityA associated 
  94. with it; PanelA object would also be responsible for storing the
  95. values away.  When EntityB needs to be drawn, construct GraphicB
  96. associated with EntityB, and send GraphicB a Draw message, along
  97. with required parameters.
  98.  
  99.  
  100. Question?
  101. ---------
  102.  
  103. Which of these 3 approaches is best?  
  104. Have any of you used an approach (or a mixture) and learnt any
  105. lessons which you would like to share?
  106. What are the pros and cons of each approach as it relates to 
  107. extensibility, maintainability, resusability, testing, proting, 
  108. and using them within C++ ?
  109.  
  110.  
  111.  
  112. -- 
  113. Rizwan Mithani ( rdm%uhura1@uunet.uu.net )
  114. *** The opinions expressed above are mine. ***
  115. *** They do not reflect the views of SAI.  ***
  116.