Re: @properties and Information Hiding
Re: @properties and Information Hiding
- Subject: Re: @properties and Information Hiding
- From: Karl Goiser <email@hidden>
- Date: Fri, 2 Nov 2007 17:30:04 +1100
Hi mmalc,
Ok, thanks for that! That seems reasonable.
So, would you recommend doing the following?
<interface file>
@interface MyClass : NSObject {
NSString *name;
}
@property(readonly, retain, nonatomic) NSString * name;
@end
<implementation file>
@interface MyClass ()
@property(readwrite, retain, nonatomic) NSString * name;
@end
@implementation MyClass
@synthesize name;
@end
Looking a bit further, there are more combinations that are possible
(and useful too!):
- Completely private setters and getters
I guess you would only put the @property in the class extension in
the .m file.
- Only a private setter, but direct getters.
What if I don't want to use a getter to access an instance variable
that I know will only be accessed from within the class, but do want
to have a synthesised setter?
Thanks!
Karl
On 02/11/2007, at 11:34 AM, mmalc crawford wrote:
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
_______________________________________________
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