home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / object / 2959 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.2 KB
  1. Path: sparky!uunet!mcsun!sun4nl!media03!pkr
  2. From: pkr@media03.UUCP (Peter Kriens)
  3. Newsgroups: comp.object
  4. Subject: Can functions be objects?
  5. Message-ID: <2840@media03.UUCP>
  6. Date: 22 Jul 92 08:29:06 GMT
  7. Organization: Mediasystemen, Netherlands
  8. Lines: 49
  9. X-Newsreader: Tin 1.1 PL4
  10.  
  11.  
  12. Functions as objects
  13. I started using OO with Smalltalk about 6 years ago. After
  14. making a million of mistakes I finally have the feeling
  15. that today I create reasonable efficient OO models and
  16. designs. 
  17.  
  18. Lately I am involved in projects where C++ is used. This
  19. projects confront me with designs which I find very 
  20. awkward. I know C++ requires a different design attitude.
  21. Classes are much cheaper and because of the static typing
  22. you need much more of them. I realize this creates a more 
  23. complex design.
  24.  
  25. However, I get the uneasy feeling that I am missing
  26. something because everybody else seems to find function objects
  27. which I regard as bad. Even in the book of Rebecca Wirfs-Brock 
  28. I am confronted with an Inquiry, a Deposit and a Withdrawal object
  29. in the ATM. In a design I am reviewing I find a XX_Create, XX_Delete 
  30. and a XX_Edit object.
  31.  
  32. My personal feeling is to immediately reject these kind of objects
  33. because they feel like they were found from structured analysis
  34. instead of object oriented analysis. They could be there because
  35. people need an abstraction mechanism to collect together a group
  36. of functions, and that is what they call a class. 
  37.  
  38. I feel strongly that an object should play an active rol in the
  39. problem domain. The Inquiry or Withdrawal are not tangible things,
  40. but just services executed by "something". By definition, the Inquiry, 
  41. the Withdrawal etc. will be closely tied together, because they will
  42. use the same kind of input/output devices and basic services.
  43.  
  44. Seperating these into a seperate class makes the communication pattern
  45. needlessly complex. And the fact the the person who wants to understand
  46. the program needs to understand more classes, will increase maintenance
  47. cost.
  48.  
  49. Why I post this question is to find out if these kind of
  50. objects are commonly regarded as good OO, and that I am
  51. standing alone, or that I am right. 
  52.  
  53. Are there things I am missing? Can "functions" 
  54. be objects?
  55.  
  56.     Peter Kriens
  57.  
  58.  
  59.  
  60.