Objective C: Differentiating iVars and Accessors

Question

 @interface RandomObject : NSObject
 {
  NSString* someObject; // I know I don't have to explicitly declare. Just to clarify my point. 
 }
 @property (nonatomic, strong) NSString *someObject;
 @end

 @implementation RandomObject 
 @synthesize someObject;
 @end

Given the code above and Xcode 4.3 is used (hence, no auto-synthesizing), here is my question.

The property/synthesize will create accessors for someObject, namely getter and setter. So if I want to assign a value to someObject, I can do this.

 self.someObject = @"Tomato"; // [self setSomeObject: @"Tomato"];

If my understanding is correct, self will send @"Tomato" to setSomeObject method. But what if you do this?

 someObject = @"Tomato"; // or maybe _someObject = @"Tomato" if you are doing auto-synthesizing

Directly accessing an iVar object seems like a bad idea, but since someObject is a private variable, within the same class you have access to that, right?

I understand why you would need to use self.someOject if you want to manipulate someObject from another class. But why is it that you'd need to do the same even though you are still in the same class. Why is it that it's a bad idea to directly access iVar.

I'm always using `someObject = @"Tomato"` instead of `self.someObject = @"Tomato"` and everything works perfectly, never encountered an error — Moray, Apr 15 '13 at 08:57
To my knowledge, these are pretty much the same thing : `self.someObject` is the value of the ivar of the object you're working on. `someObject` is the variable declared locally, in this case, it is the ivar declared in the header file. So using `self.someObject` will look to ivars of `self` and then find the ivar called `someObject` whereas `someObject` will assign directly the value to the ivar since it's declared as an ivar. Tell me if I'm wrong. — Moray, Apr 15 '13 at 09:07
possible duplicate of [iOS: must every iVar really be property?](http://stackoverflow.com/questions/5031230/ios-must-every-ivar-really-be-property) — Monolo, Apr 15 '13 at 10:10
@Moray you are not wrong in that both allow you to work with the ivar but the way they allow you to do this is very different and with the accessor there is a level of abstraction introduced between your code and the ivar which is generally a good thing — Paul.s, Apr 15 '13 at 10:13

score 3 · Answer 1 · answered Apr 15 '13 at 10:10

Generally speaking accessors have more pros than cons and I use them everywhere I can.

The main issue is that every place you reference the ivar directly is another potential place your code will need to change.

For example imagine you have referenced someObject in multiple places throughout your class. Then the requirements change and now you decide that when the value of someObject is assigned you need to so some other work. Due to the fact that you have accessed the ivar directly throughout the class you now have to either duplicate this new code everywhere you assign someObject or refactor. If you was using an accessor you just have one piece of code to change

- (void)setSomeObject:(id)anObject
{
  if (anObject != someObject) {
    someObject = anObject;
    [self doSomeWork];
  }
}

You can have the same issue with the getter - imagine you store an array of objects in someObjects - this works great but then later down the line you decide that you don't actually need to store someObjects as it can be dynamically computed from other values. If you have directly accessed the ivar everywhere then this becomes a big chore. If you stick to abstracting someObject behind a getter then all you now have to do is

- (NSArray *)someObjects
{
   return [self calculateSomeObjects];
}

This is exactly the idea with non-ARC code, which puts the memory management of the ivar in one place (behind accessors) so that you do not have to litter your code with repetitive code.

score 2 · Accepted Answer · edited May 23 '17 at 11:43

The property does more than just assigning an object to the ivar.

If you don't use ARC, the property will auto-generate retain/release code to handle memory management. Just calling someObject = @"Tomato" creates a memory leak (if someObject is assigned)

If your property is atomic, the property will provide thread safety, while accessing the ivar would not be thread safe.

See https://stackoverflow.com/a/589348/1597531 for examples of auto-generated property code.

Objective C: Differentiating iVars and Accessors

2 Answers2