home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / object / 3056 < prev    next >
Encoding:
Text File  |  1992-07-29  |  2.3 KB  |  53 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!projtech!sanjiv
  3. From: sanjiv@projtech.com (Sanjiv Gossain)
  4. Subject: Re: Can functions be objects?
  5. Message-ID: <1992Jul29.180139.7333@projtech.com>
  6. Organization: Project Technology, Inc., Berkeley, CA
  7. References: <2840@media03.UUCP> <knight.712244466@cunews>
  8. Date: Wed, 29 Jul 1992 18:01:39 GMT
  9. Lines: 42
  10.  
  11. In article <knight.712244466@cunews> knight@mrco.carleton.ca (Alan Knight) writes:
  12. >In <2840@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes:
  13. >
  14. >>However, I get the uneasy feeling that I am missing
  15. >>something because everybody else seems to find function objects
  16. >>which I regard as bad. Even in the book of Rebecca Wirfs-Brock 
  17. >>I am confronted with an Inquiry, a Deposit and a Withdrawal object
  18. >>in the ATM. In a design I am reviewing I find a XX_Create, XX_Delete 
  19. >>and a XX_Edit object.
  20.  
  21. [ various stuff deleted ]
  22. >
  23. >It seems to me that there is a considerable difference between "plays
  24. >an active role in the problem domain" and "are tangible things". The
  25. >different kinds of transactions certainly play an important role in
  26. >the domain. They just aren't tangible. I think that trying to restrict
  27. >objects to things that can be picked up and thrown is a bad idea. 
  28.  
  29. I would agree here, although I would suggest that bothe Roles and Tangible
  30. Things are valid objects during analysis. Tangible things in the 
  31. problem domain are just *one* kind of object that one can identify 
  32. during analysis. The objects that Peter referred to (XX_Create, 
  33. XX_Delete, ..) if they are separate objects, are certainly in my 
  34. opinion "incorrect". 
  35.  
  36. One useful technique which is useful when trying 
  37. to capture the semantics of the problem domain
  38. is to think of the different categories of objects one can have:
  39. tangible things, roles, incidents, interactions, and specifications.
  40. Then try and look at your problem and see if you can identify objects
  41. from each category in the problem domain. Each category can introduce 
  42. objects during analysis. Thus using such a scheme objects such as 
  43. Deposit, Withdrawal could be seen as objects (in the incident category).
  44. However, XX_Create, XX_Delete would not.
  45.  
  46.     - Sanjiv
  47.  
  48. -- 
  49. ----------------
  50. Sanjiv Gossain        sgossain@projtech.com
  51. Project Technology    Training and Consulting using Shlaer-Mellor OOA/RD
  52. Berkeley, CA        (510) 845 1484
  53.