Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You should always use accessors of properties (which in Objective-C 2.0 means using the <code>self.property</code> notation.)</p> <p>Why? Because it provides automatic access control and object life-cycle management. The generated accessors can provide a lot protection, such as read/write, copy, retain etc that take a lot of manual code otherwise. If you write your own accessors, you can add in all the validation and side effects you want. </p> <p>(Back before Objective-C 2.0 writing accessors was considered a high art. It still can be if you fully exploit the potential.)</p> <p>The only time you should access properties directly is when you are writing an accessor. For example take this common pattern:</p> <pre><code>@property(nonatomic, retain) NSMutableArray *myObjects; @synthesize myObjects; -(NSMutableArray *) myObjects{ if (myObect!=nil) { return myObect; } NSMutableArray *anArray=[[NSMutableArray alloc] initWithCapacity:1]; self.myObject=anArray; [anArray release] return myObject; } </code></pre> <ol> <li>This accessor ensures that myObjects is never nil which removes a lot of boilerplate nil testing in the rest of your code. </li> <li>You obviously can't call <code>self.myObjects</code> (which is really [self myObjects] )inside the accessor without creating an infinite recursion so you must access the raw variable here but...</li> <li>...You can call (the autogenerated) <code>self.myObjects=</code> (which is really [self setMyObjects:anArray] ) because it's an entirely different method. If you look at the internals of setMyObjects: you would see that it access the raw variable as well. </li> <li>If you use the generated accessors, <code>self.myObjects=</code> handles retaining, copying, nilling etc for you, every time you call it. The only time you have to call release is in the dealloc. This alone wipes out probably half the errors people make in Objective-C.</li> </ol> <p>Conversely, outside of an accessor method, you gain absolutely nothing by directly accessing the properties inside the classes own methods. All it does is save some key strokes while exposing you to the risk of hard to find bugs. </p> <p>As the previous answers demonstrated, you made several memory errors by trying to manage the property directly. Had you used the accessor every time, you would not have made them. For example:</p> <pre><code>pickerData = [[[NSArray alloc] initWithObjects:@"A", @"B", @"C", nil] retain]; </code></pre> <p>... has to be managed exactly right every time whereas ...</p> <pre><code>self.pickerData = [[NSArray alloc] initWithObjects:@"A", @"B", @"C", nil]; </code></pre> <p>... is automatically correct. </p> <p>Remember that the ultimate design goal for any Objective-C class is that is should be perfectly modular and reusable. That means it should manage all its own memory, its own data validation and its own side effects. Accessors are absolutely vital to that management. By wrapping logic around every access of a variable, you ensure that (1) it is the type, range, etc you expect and (2) that it is always around when you need it be (3) that you can control all the side effects of writing or reading the variable and (4) that it doesn't leak. </p> <p>I cannot extol the virtues of accessors enough. In fact, I might write a little song. ;-)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload