home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / mac / programm / 18581 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  2.2 KB
  1. Path: sparky!uunet!sun-barr!cs.utexas.edu!sdd.hp.com!spool.mu.edu!sol.ctr.columbia.edu!ira.uka.de!math.fu-berlin.de!unidui!Germany.EU.net!mcsun!sunic!lunic!my!sm-emac15.sm.luth.se!matti
  2. From: matti@my.sm.luth.se (Matti Larborn)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: Think Pascal - Whats the latest version ?
  5. Message-ID: <1353@my.sm.luth.se>
  6. Date: 18 Nov 92 10:00:42 GMT
  7. References: <6746@m1.cs.man.ac.uk>
  8. Sender: news@sm.luth.se
  9. Organization: Lule} University
  10. Lines: 42
  11. X-UserAgent: Nuntius v1.1.1d11
  12. X-XXMessage-ID: <A72FD2D8C302037B@sm-emac15.sm.luth.se>
  13. X-XXDate: Wed, 18 Nov 92 10:00:40 GMT
  14.  
  15. In article <1992Nov18.172004.12287@waikato.ac.nz> Lawrence D'Oliveiro,
  16. ldo@waikato.ac.nz writes:
  17. >Why bother? There are too many potential complications with this scheme:
  18. >
  19. >* What if you want the user to be able to read, but not write those
  20. fields?
  21. >* What if you want the user to be able to write those fields in a certain
  22. >  restricted fashion to preserve certain relationships to the values in
  23. >  other fields?
  24.  
  25. If you want the user to be able to access or modify these fields you
  26. should have modifiers and accessors. In this way you can control what the
  27. user can do.
  28.  
  29. If the data structure is visible the user can store whatever he likes
  30. into those fields!
  31.  
  32. >* What if you later decide not to store that field, but compute it from
  33. >  some other fields? Changing this would break existing clients.
  34.  
  35. If you change the field or remove it, it shouldn't be of so much
  36. importance and therefore unreferenced, or with few references to it. The
  37. changes wouldn't be so big. Otherwise if you change an important field
  38. you change the behavior of the whole object and in this case I wonder
  39. what you where doing in the first place.
  40.  
  41. With good data abstraction the client shouldn't know anything about the
  42. implementation and therefore it should be possible to change the
  43. implementation whenever you want.
  44.  
  45. >A simpler and more general approach is to define accessor procedures and
  46. >functions. These can enforce any constraints you like. And they don't
  47. need
  48. >a new language feature!
  49.  
  50. Yes, but these doesn't prevent you from accessing the data directly!
  51. (Without using your accessors)
  52.  
  53.     --Matti Larborn, Sweden.
  54.  
  55.  
  56. ----- More security to the data! -----
  57.