home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / object / 3017 < prev    next >
Encoding:
Text File  |  1992-07-27  |  3.6 KB  |  78 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!caen!destroyer!gumby!wupost!news.utdallas.edu!corpgate!bnrgate!nrcnet0!cunews!cunews!knight
  3. From: knight@mrco.carleton.ca (Alan Knight)
  4. Subject: Re: Can functions be objects?
  5. Message-ID: <knight.712244466@cunews>
  6. Sender: news@cunews.carleton.ca (News Administrator)
  7. Reply-To: knight@mrco.carleton.ca (Alan Knight)
  8. Organization: Carleton University
  9. References: <2840@media03.UUCP>
  10. Date: Mon, 27 Jul 1992 13:41:06 GMT
  11. Lines: 65
  12.  
  13. In <2840@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes:
  14.  
  15. >However, I get the uneasy feeling that I am missing
  16. >something because everybody else seems to find function objects
  17. >which I regard as bad. Even in the book of Rebecca Wirfs-Brock 
  18. >I am confronted with an Inquiry, a Deposit and a Withdrawal object
  19. >in the ATM. In a design I am reviewing I find a XX_Create, XX_Delete 
  20. >and a XX_Edit object.
  21.  
  22. >My personal feeling is to immediately reject these kind of objects
  23. >because they feel like they were found from structured analysis
  24. >instead of object oriented analysis. They could be there because
  25. >people need an abstraction mechanism to collect together a group
  26. >of functions, and that is what they call a class. 
  27.  
  28. >I feel strongly that an object should play an active rol in the
  29. >problem domain. The Inquiry or Withdrawal are not tangible things,
  30. >but just services executed by "something". By definition, the Inquiry, 
  31. >the Withdrawal etc. will be closely tied together, because they will
  32. >use the same kind of input/output devices and basic services.
  33.  
  34. It seems to me that there is a considerable difference between "plays
  35. an active role in the problem domain" and "are tangible things". The
  36. different kinds of transactions certainly play an important role in
  37. the domain. They just aren't tangible. I think that trying to restrict
  38. objects to things that can be picked up and thrown is a bad idea. 
  39.  
  40. It's certainly true that objects representing functions can be a
  41. symptom of bad design, but they can also be a very good thing.  I
  42. personally think XX_Create, XX_Edit etc. sounds suspicious, whereas
  43. Inquiry, Withdrawal, etc. sound pretty reasonable.
  44.  
  45. IMHO, if you can give something a reasonable name then it's a good
  46. candidate for an object. XX_Create probably isn't a reasonable name
  47. for an object because it sounds too much like a method name. On the
  48. other hand XX_Reader, which reads objects of type XX from a file,
  49. might be (depends how complicated reading is, and whether it's
  50. possible to write a general File_Reader). 
  51.  
  52. This is true whether the thing you are naming is tangible or not.
  53. Consider another example, Colour. Colour is not a concrete thing in
  54. itself, it's just an attribute belonging to some other thing. Would it
  55. be ridiculous to make Colour an object in its own right? I don't think
  56. so. 
  57.  
  58. You point out that Inquiry and Withdrawal will have much in common.
  59. This is true, but argues that they should probably both be subclasses
  60. of the abstract class Transaction, as much as it argues for them to be
  61. methods. 
  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. True, but taking something with a complicated functionality and
  69. spreading it out into one or more places it doesn't belong is also a
  70. bad thing. This is a matter of design, and is true whether you're
  71. dealing with objects that are tangible or not. 
  72.  
  73. -- 
  74.  Alan Knight  knight@mrco.carleton.ca  +1 613 788 2600x5783   Join
  75.  Dept. of Mechanical and Aerospace Engineering                the
  76.  Carleton University, Ottawa, Ontario, Canada, K1S 5B6        LPF
  77.  
  78.