Re: @properties and Information Hiding
Re: @properties and Information Hiding
- Subject: Re: @properties and Information Hiding
- From: mmalc crawford <email@hidden>
- Date: Thu, 1 Nov 2007 17:34:34 -0700
On Nov 1, 2007, at 3:57 PM, Karl Goiser wrote:
So, let's make a comparison using class extensions (this seems to me
to be the most applicable because it allows the compiler to do more
checking which is good):
[...]
If so, this hardly seems like an advantage. Sure, the number of
lines has decreased, but that is mostly in terms of white space, and
only marginally - and traded off with hiding the implementation of
the actual methods.
It may not appear much of an advantage for one property, however if
you spread this over numerous properties the effect is more
noticeable. Particularly when you have properties that are publicly
declared as readwrite so you don't have to do the category dance. The
effect is especially noticeable for Core Data (see <http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdAccessorMethods.html
>).
There are two additional considerations:
(a) You have incorrectly specified your property; given the
implementation you seem to want, it should be:
@property(readonly, retain, nonatomic) NSString *value;
By default properties are atomic, so you're actually "not seeing"
considerably more code than you first showed.
(b) Consumers of your class now see, instead of:
@interface MyClass : NSObject {
NSString *value;
}
- (NSString *) value;
@end
this:
@interface MyClass : NSObject {
NSString *value;
}
@property(readonly, retain [, nonatomic]) NSString *value;
@end
This makes your intent for the property much more clear.
Also, there were three places where I have to worry about the
instance variable (in the class declaration, getter method
declaration and method implementations), now there are four (in the
class declaration, getter method declaration, class extension and
synthesize statement). which won't make maintenance any easier.
It's not clear exactly what you mean by "worrying about the instance
variable".
One of the attractions of properties is that they're not tied to an
instance variable -- you can rename either the ivar or the property
and "redirect" using the synthesize directive 'ivar='.
Moreover, in the traditional case you certainly have more than three
places where the property/ivar name is required:
@interface MyClass : NSObject {
NSString *value; // 1
}
- (NSString *) value; // 2
@end
<implementation file>
@implementation MyClass
- (NSString *) value /* 3 */ {return value /* 4 */};
- (void) setValue: /* 5 */ (NSString *) stringParameter {
[stringParameter retain];
[value release]; //6
value = stringParameter; // 7
}
I don't think the burden of properties is any greater.
And in the case of 64-bit, you don't have to worry about the actual
instance variable at all. Thus you would simply have:
@interface MyClass : NSObject {
}
@property(readonly, retain [, nonatomic]) NSString *value;
@end
...
@synthesize value;
... etc.
mmalc
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden