Re: Another controversial question
Re: Another controversial question
- Subject: Re: Another controversial question
- From: Alykhan Jetha <email@hidden>
- Date: Sun, 2 Sep 2001 12:34:40 -0400
The original intent of key-value coding was to simplify access
to **public** attributes (those with get/set methods) of an
object from something like a textfield in a UI, or walking an
object graph without having to code the path. It is *extremely*
useful when you get to an object deep in your object graph from
a UI building such as IB or WOBuilder. KeyValue coding is
particularly useful when working with EOF (in fact it was
introduced with EOF, then it was moved to foundation).
Somewhere along the line, not sure when, Apple or NeXT enabled
the key-value coding mechanism to read ivars directly. I don't
agree with this at all, but there must be good reason for it
(most likely scripting support -- remember Webscript?).
Thankfully you can turn these feature off by invoking the
following snippet of code:
+ (BOOL)accessInstanceVariablesDirectly
{
return NO;
}
See NSKeyValueCoding.html for more info.
Key-value coding behavior is such that if you have get/set
methods, it will use those. Only if you don't have those
methods, then it accesses the ivar directly.
Valid methods assuming ivar name is 'name':
- (NSString *)name;
- (NSString *)_name;
- (NSString *)getName;
- (NSString *)_getName;
- (void)setName:(NSString *)aValue;
- (void)_setName:(NSString *)aValue;
So, it only violates OO principals when you allow it to access
your ivars directly (which unfortunately is the default
behavior).
but it also seems to introduce stronger coupling between
classes, which is generally undesirable.
I don't see how you came to this conclusion?? On the contrary it
allows for less coupling between classes, because you don't even
need to know the class to access an attribute.
If you are really paranoid, you can name your ivars differently
than your accessor methods:
NSString *_private_name;
- (NSString *)name
{
return _private_name;
}
The following code would produce an uppercase version of _private_name
[myObject valueForKeyPath:@"name.uppercaseString"];
I'm not sure I addressed all of you concerns ...
Hope this helps ...
./aj
On Sunday, September 2, 2001, at 11:16 AM, Drew McCormack wrote:
Can anyone tell me why key-value coding is not a serious
violation of encapsulation, and therefore also a violation of
object-oriented principles?
Everyone took a shot at me for suggesting that inheritance of
constructors was not such a good idea. The general feeling
seemed to be that if you didn't inherit constructors, you were
violating an important aspect of OO.
Yet, when I see key-value coding, it scares me to death. Maybe
I have missed the point, but it seems this is a way of changing
the internal state of an object by bypassing the accessor
methods provided. This, of course, defeats the purpose of
having accessor methods in the first place, which is to
introduce indirection such that the implementation of a class
can change independent of its interface.
Can any experienced Cocoa programmers out there tell me if they
use key-value coding, and if so, under what circumstances? I
can certainly see that it makes coding much easier, but it also
seems to introduce stronger coupling between classes, which is
generally undesirable.
I'm not trying to start trouble here, but I would like to
understand the reasoning behind it more fully.
Drew McCormack
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev