home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11356 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  2.6 KB
  1. Path: sparky!uunet!mcsun!fuug!demos!kiae!glas!demos!ucc.su.oz!extro.ucc.su.OZ.AU!maxtal
  2. From: maxtal@extro.ucc.su.OZ.AU
  3. Newsgroups: comp.lang.c++
  4. Date: 17 Jul 92 20:07 MDT
  5. Subject: Re: many set/get member functions in a 
  6. Sender: Notesfile to Usenet Gateway <notes@glas.apc.org>
  7. Message-ID: <1992Jul17.160748.28162@ucc.su.oz>
  8. References: <1992Jul08.121838.13948@jho.com>
  9. Nf-ID: #R:1992Jul08.121838.13948@jho.com:2043735141:1992Jul17.160748.28162@ucc.su.oz:1351187194:001:2133
  10. Nf-From: extro.ucc.su.OZ.AU!maxtal    Jul 17 20:07:00 1992
  11. Lines: 59
  12.  
  13.  
  14. In article <rmartin.711297034@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
  15. >maxtal@extro.ucc.su.OZ.AU (John (MAX) Skaller) writes:
  16. >|
  17. >|    In short, making the variable public is safer and more
  18. >|    correct IMHO. Use get and set only under duress.
  19. >
  20. >I disagree.  Under no circumstances should an instance variable be
  21. >directly manipulated by a client.  To do so is to abandon the
  22. >abstraction of the server, and tie the clients hopelessly to its
  23. >implementation. 
  24.  
  25.     No and yes respectively :-)
  26.  
  27.     The public variable ENFORCES a particular semantics,
  28. and if that happens to be the desired abstraction, use it.
  29.  
  30. >
  31. >get/set functions are not much better, but every little bit counts.
  32.  
  33.     I contend that perhaps sometimes the ADVANTAGE of enforced
  34. semantics outweighs the disadvantage of loss of independence
  35. from representation: it does so when that abstraction
  36. corresponds directly to an existent type variable.
  37.  
  38. >If you really and truly cannot find a way to get rid of your get/set
  39. >functions, then put them in, they are preferable to declaring your
  40. >member variables public.
  41.  
  42.     Not convinced. Where a change in implementation would
  43. ALWAYS be a change in semantics then the variables are best
  44. because the FORCE you to examine every use, as a change in
  45. semantics should.
  46.  
  47.     The get/set hides BOTH the semantics and the representation,
  48. the former is not desirable while the latter is.
  49. >
  50. >But, try hard to get rid of most of your get/set functions.  They are
  51. >strong indicators of an incomplete abstraction. 
  52. >
  53.  
  54.     Usually, yes. I agree in principle.
  55.     There are SOME cases where a simple public data
  56.     structure is useful. Quite a few, actually.
  57.  
  58.     Not all programming in C++ is OO.
  59.  
  60.     But for many abstractions, public data is not desirable.
  61.  
  62.     Proper semantics specification is, but that is not
  63.     in the language, not even preconditions, invariants
  64.     etc which Eiffel has.
  65.  
  66. -- 
  67. ;----------------------------------------------------------------------
  68.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  69.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  70. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  71.  
  72.