home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / object / 2979 < prev    next >
Encoding:
Text File  |  1992-07-22  |  3.9 KB  |  90 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!mole-end!mat
  3. From: mat@mole-end
  4. Subject: Re: Can functions be objects?
  5. Message-ID: <1992Jul22.184151.23629@mole-end>
  6. Summary: Transaction Records
  7. Organization: :
  8. References: <2840@media03.UUCP>
  9. Date: Wed, 22 Jul 1992 18:41:51 GMT
  10. Lines: 78
  11.  
  12. In article <2840@media03.UUCP>, pkr@media03.UUCP (Peter Kriens) writes:
  13.  
  14. > Functions as objects
  15.  
  16. > I started using OO with Smalltalk about 6 years ago.  ...  I finally
  17. > have the feeling that today I create reasonable efficient OO models and
  18. > designs. 
  19.  
  20. > Lately I am involved [with] C++ .... This ... confront[s] me with
  21. > designs which I find very awkward. I know C++ requires a different
  22. > design attitude. ...
  23.  
  24. > However, I get the uneasy feeling that I am missing something because
  25. > everybody else seems to find function objects which I regard as bad.
  26. > Even in the book of Rebecca Wirfs-Brock I am confronted with an Inquiry,
  27. > a Deposit and a Withdrawal object in the ATM. In a design I am reviewing
  28. > I find a XX_Create, XX_Delete and a XX_Edit object.
  29.  
  30. These aren't necessarily bad.  To begin with, think of a `transaction
  31. record' which is needed hold the state of a transaction across several
  32. other steps.
  33.  
  34. Actions-as-objects are often used when several objects must take active
  35. roles, and something else must coordinate their activities, making
  36. decisions on information that transcends the state of any of the
  37. individual objects, or providing state store that is related to the
  38. `process' at hand.
  39.  
  40. Id _does_ deviate from the `simulation' heritage of OO, in which the
  41. interrelationship of object behavior is investigated--but when the
  42. interrelationship of object behavior is to be _specified_, as it is
  43. in engineered software, such objects have a place.
  44.  
  45. > My personal feeling is to immediately reject these kind of objects
  46. > because they feel like they were found from structured analysis instead
  47. > of object oriented analysis. They could be there because people need
  48. > an abstraction mechanism to collect together a group of functions, and
  49. > that is what they call a class. 
  50.  
  51. If what you need is a JUST cluster of functions, then it's probably not
  52. a good object.  But if you need to coordinate the activities of other
  53. objects in a shared activity, or store state information unique to the
  54. activity, or make decisions that depend on the state of several objects
  55. at once, you may have a good candidate for an object.
  56.  
  57. > I feel strongly that an object should play an active rol in the
  58. > problem domain. The Inquiry or Withdrawal are not tangible things,
  59. > but just services executed by "something". By definition, the Inquiry, 
  60. > the Withdrawal etc. will be closely tied together, because they will
  61. > use the same kind of input/output devices and basic services.
  62.  
  63. > Seperating these into a seperate class makes the communication pattern
  64. > needlessly complex. And the fact the the person who wants to understand
  65. > the program needs to understand more classes, will increase maintenance
  66. > cost.
  67.  
  68. Often, using an object to manage a `transaction' is the only way to
  69. bring the communication patterns under control, especially when loops
  70. in the message flow might otherwise occur.
  71.  
  72. Also, when several activities have similar patterns, it may be possible
  73. to share design by inheritance, and to thereby improve the program
  74. structure.
  75.  
  76. > Why I post this question is to find out if these kind of objects are
  77. > commonly regarded as good OO, and that I am standing alone, or that I am
  78. > right. 
  79.  
  80. One thing that you MUST realize in asking questions like this is that
  81. there are three more-or-less distinct communities using OO: Simulation,
  82. Prototyping, and Engineered Software.  The first two are research activities;
  83. the third a development activity.  The first two produce _results_ as
  84. their product; the third produces a _program_ as its product.
  85. -- 
  86.  (This man's opinions are his own.)
  87.  From mole-end                Mark Terribile
  88.  
  89.  uunet!mole-end!mat, Somewhere in Matawan, NJ
  90.