home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / object / 4650 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  4.5 KB
  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!ogicse!cadreor!fripp!usenet
  2. From: jc@ri.cadre.com (Joe Cascio)
  3. Newsgroups: comp.object
  4. Subject: Re: Object Relations - was: Re: Object hidd
  5. Message-ID: <1992Dec23.144503.15510@fripp.ri.cadre.com>
  6. Date: 23 Dec 92 14:45:03 GMT
  7. Article-I.D.: fripp.1992Dec23.144503.15510
  8. References: <92Dec22.170044.16343@acs.ucalgary.ca>
  9. Sender: usenet@fripp.ri.cadre.com (USENET News Poster Account)
  10. Reply-To: jc@ri.cadre.com
  11. Organization: Cadre Technologies Inc., Providence, RI
  12. Lines: 90
  13. Nntp-Posting-Host: 192.9.200.27
  14.  
  15. >This is probably where these secondary relationships should be
  16. >controlled - in the lowest common aggregator.  But sometimes, for
  17. >efficiency reasons, I don't do that.  Instead of having the
  18. >"transportation system" control the relationship between the (car
  19. >with wheels) and the road, I have the wheels containing a pointer
  20. >to the surface that they are on.  This can cause maintenance and
  21. >debugging nightmares, but it seems to be necessary on
  22. occasion.
  23.  
  24. A classic tradeoff:  run-time efficiency vs. maintainability.
  25.  
  26. I have had the same experience.  One technique we've borrowed from
  27. the X window system that seems to help is to use callback function
  28. pointers.  When the aggregator creates the constituent, two of the
  29. arguments to the constructor are a pointer to one of the
  30. aggregator's functions that returns the "type of road" in your
  31. example, and a void* that is the address of the aggregator.  When
  32. the wheel needs to know "type" of road, it calls the function
  33. pointer, passing back the void*.  This technique allows the
  34. constituent to remain type-decoupled from the aggregator, and
  35. hence re-usable in the absence of the aggregator type, although
  36. it requires the aggregator to cast the void* to it's own type.
  37.  
  38. Another solution is to pass the information as an argument only when
  39. it is needed.
  40.  
  41. >relationship.  This causes problems if the lifetime of the
  42. >relationship is terminated by the "transportation system" and
  43. >no-one bothers to tell the wheel about it.
  44. >>
  45.  
  46. Functional dependency, no?  It seems like the maintenance of
  47. that relationship is the aggregator's responsibility.
  48.  
  49. >Things I don't like about this solution (although it's the
  50. >only one I've got so far):
  51. >1) the "super-aggregator" can end
  52. >up containing virtual all of the secondary relationships in the
  53. >application.
  54.  
  55. True.  But, better there than spread over all the constituent
  56. objects, I think.
  57.  
  58. >2) it cuts down on re-use possibilities - no one
  59. >else would be able to re-use my car object without creating their
  60. >own object that can tell my car what surface its wheels are on.
  61. >
  62.  
  63. On the contrary, I think it improves re-usability.  Better that
  64. the re-user should be able to specify the environment, than be
  65. forced to live with one that comes along with something it wants
  66. to use.
  67.  
  68. At a certain level, I think you give up re-usability of the car
  69. when you make it worry about the type of road it's on for
  70. efficiency purposes.  If the "car-is-on-road" relationship handled
  71. those functions (and associative objects can do that!), then the
  72. car would remain perfectly re-usable in the absence of a road.
  73. Also, it seems like a perfectly reasonable thing to ask of the
  74. user of a car to be responsible for telling the car what type of
  75. road it's on.
  76.  
  77. >tran.sys controls (owns) the relationships between them, but
  78. >these relationships are, at least temporarily, independant of the
  79. >tran.sys.
  80.  
  81. Again, it seems like maintenance of "transient" relationships like
  82. this are the responsibility of the common "owner" object.  The
  83. trans.sys could tell the truck about the driver until another
  84. driver is assigned.
  85.  
  86. I guess what I'm trying to say with all this is that when two
  87. objects come together in other than an "owns" relationship, it is
  88. the responsibility of a common owner to dictate how they interact.
  89. Otherwise, parts of the common owner begin to "leak" into the
  90. constituents, causing them to become less re-usable in other
  91. environments where the owner is not needed.  You may have to do
  92. that for efficiency, but you pay the price in maintainability.
  93.  
  94. ---
  95. ==============================================================
  96. * Joe Cascio                u----wm-
  97. * Cadre Technologies Inc.        /\
  98. * 222 Richmond St.              0_/  "$@@#!$#@$^&"
  99. * Providence, RI 02903 USA       \
  100. * phone: 401-351-5950             |     . .
  101. * FAX  : 401-455-6803            /|   .    .   . .
  102. * email: jc@cadre.com           / | .       . .   . . .
  103.                                ^  ^          .     .   . ....
  104. ==============================================================
  105.