home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / next / programm / 7322 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  2.4 KB

  1. Xref: sparky comp.sys.next.programmer:7322 comp.lang.objective-c:675
  2. Newsgroups: comp.sys.next.programmer,comp.lang.objective-c
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!psinntp!psinntp!afs!michael
  4. From: Michael_Pizolato@afs.com (Michael Pizolato)
  5. Subject: Proper way to access superclass instance variables
  6. Message-ID: <1992Nov18.213742.493@afs.com>
  7. Followup-To: comp.lang.objective-c
  8. Sender: michael@afs.com
  9. Reply-To: Michael_Pizolato@afs.com
  10. Date: Wed, 18 Nov 1992 21:37:42 GMT
  11. Lines: 81
  12.  
  13. A question of philosophy.  Consider the following classes:
  14.  
  15. @interface Foo:Object
  16.    {
  17.    int value;
  18.    }
  19. - setValue:(int)aValue;
  20. - (int)value;
  21. @end
  22.  
  23. @implementation Foo
  24. - setValue:(int)aValue
  25.    {
  26.    value = aValue;
  27.    return self;
  28.    }
  29.  
  30. - (int)value
  31.    {
  32.    return value;
  33.    }
  34. @end
  35.  
  36. @interface Bar:Foo
  37.    {
  38.    }
  39. - mungValue;
  40. - buggerValue;
  41. @end
  42.  
  43. @implementation Bar
  44. - mungValue
  45.    {
  46.    value += 2;
  47.    }
  48.  
  49. - buggerValue
  50.    {
  51.    [self setValue:[self value] + 2];
  52.    }
  53. @end
  54.  
  55. Which method in Bar is better as far as accessing the instance variable 'value' from Foo?  I say -buggerValue is better because if Foo is in a library I have obtained from some vendor, and that vendor changes the representation of 'value' and sends me an upgrade, my code still works.  The method -mungValue could fail if the representation of 'value' changes.  For example, if the Foo class changes to this:
  56.  
  57. @interface Foo:Object
  58.    {
  59.    double v1, v2;
  60.    }
  61. - setValue:(int)aValue;
  62. - (int)value;
  63. @end
  64.  
  65. @implementation Foo
  66. - setValue:(int)aValue
  67.    {
  68.    v1 = v2 = (double)aValue / (double)2.0;
  69.    return self;
  70.    }
  71.  
  72. - (int)value
  73.    {
  74.    return (int)(v1 + v2);
  75.    }
  76. @end
  77.  
  78. There's not even a 'value' ivar anymore.  I can't think of any good reason to access 'value' directly unless I have complete control over the implementation of the Foo class.  Even if I do, it's painful to change every subclass of Foo that might use 'value' directly if I change Foo as above.  Obviously, the above code is only a trivial and flawed example, but other, important data representations can change, and should change if we find better ways to do things.  For encapsulation to work properly, we shou
  79.  
  80.  
  81. ld bugger and not mung. ;-)
  82.  
  83. Any thoughts?
  84.  
  85. Thanx,
  86. Michael
  87.  
  88. P.S.  Given the conclusion that ivars should only ever be accessed through methods, it seems wrong that they appear in the @interface section.  Of course we can't change it now, but does anyone know why they're there?
  89.  
  90. --
  91. Michael_Pizolato@afs.com
  92. ~18 kyu
  93. Q16
  94. NeXTMail appreciated
  95.