问题
I've seen code examples (from the book Beginning iPhone 4 Development) where they both declare ivars inside the interface block and then declare properties for the same. Like this:
@interface ViewController : UIViewController {
UITableView *table;
}
@property (nonatomic, retain) IBOutlet UITableView *table;
What would be the purpose/benefit of this? As I understand that with the modern runtime version (iPhone and 64-bit OS X applications) you only need to declare properties and can leave out declaring the ivars inside the interface block. According to this answer in a similair thread it would be for debugging purposes. But are there any other benefits except for debugging that you would use this approach?
Cheers,
Peter
回答1:
Explicitly declaring ivars gives you the possibility to internally use a specialized type for the ivar.
A typical example is an internally mutable object that can be accessed from outside in a readonly, immutable way.
Example:
@interface Foo : NSObject
@property (readonly) NSArray *bars;
@end
@implementation
{
NSMutableArray *bars;
}
@synthesize bars;
- (void)addBar:(Bar *)bar
{
[bars addObject:bar];
}
@end
Of course the object returned from the bars
property is not really immutable. But the point is that the API does not reveal its mutability.
Note that I used the fancy new private-ivars-in-implementation style. It's depending on the modern runtime as well as the clang compiler.
回答2:
Some programmers like to define their iVars with a slightly different name to differentiate between direct access and KVC access. For example:
in the .h
@interface ViewController : UIViewController {
UITableView *_table;
}
@property (nonatomic, retain) IBOutlet UITableView *table;
and in the .m
@synthesize table = _table;
this way you directly access the iVar using _table
but you use the synthesized setters and getters using [self table]
回答3:
But are there any other benefits except for debugging that you would use this approach?
i declare the ivars explicitly for:
- access control (visibility)
- organization
- uniform written style
- compatibility (hey, this program could support 32 bit one day)
- and because i associate properties as a part of the class's public interface (although exceptions to this exist) - not simply as accessors to the class's ivars.
"everything as a read/write property" is fundamentally flawed ood.
来源:https://stackoverflow.com/questions/6099677/objective-c-modern-runtime-using-both-properties-and-ivars-in-interface-block