• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: @properties and Information Hiding
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: @properties and Information Hiding
      • From: mmalc crawford <email@hidden>
References: 
 >@properties and Information Hiding (From: Karl Goiser <email@hidden>)
 >Re: @properties and Information Hiding (From: Raffael Cavallaro <email@hidden>)
 >Re: @properties and Information Hiding (From: Karl Goiser <email@hidden>)
 >Re: @properties and Information Hiding (From: mmalc crawford <email@hidden>)

  • Prev by Date: Re: CALayer vs Layer Backed Views
  • Next by Date: Re: CALayer vs Layer Backed Views
  • Previous by thread: Re: @properties and Information Hiding
  • Next by thread: Re: @properties and Information Hiding
  • Index(es):
    • Date
    • Thread