Objective C - Using property get accessor vs directly using iVar

Question

I was wondering what exactly are the differences between using the (get) accessor for reading the value of property and directly using the iVar?

Say I have a class which declares a property:

@interface Foo : NSObject

@property (strong) NSString *someString;

@end

And in the implementation I'm using it. Are there any differences between the following two lines:

someLabel.text = self.someString;

someLabel.text = _someString;

For set accessors it's clear. Afaik for strong properties the accessor takes care of retain and release (an interesting 'side question' would be if ARC changes that, ie does setting the iVar directly [assuming it's not an __weak iVar] also retain and release correctly using ARC), also KVO requires the use of accessors to work properly etc. But what about getters?

And if there's no difference, is there one way considered best practice?

Thx

Answer 1

As you know, calling self.someString is really [self someString] . If you chose to create a property then you should use the property. There may be other semantics added to the property. Perhaps the property is lazy loaded. Perhaps the property doesn't use an ivar. Perhaps there is some other needed side effect to calling the property's getter. Maybe there isn't now but maybe this changes in the future. Calling the property now makes your code a little more future proof.

If you have an ivar and a property, use the property unless you have explicit reason to use the ivar instead. There may be a case where you don't want any of the extra semantics or side effect of the property to be performed. So in such a case, using the ivar directly is better.

But ultimately, it's your code, your property, your ivar. You know why you added a property. You know any potential benefits of that property, if any.

Answer 2

I think this what you are looking for. Why use getters and setters?

There are actually many good reasons to consider using accessors rather than directly exposing fields of a class - beyond just the argument of encapsulation and making future changes easier.

Here are the some of the reasons I am aware of:

• Encapsulation of behavior associated with getting or setting the property - this allows additional functionality (like validation) to be added more easily later.
• Hiding the internal representation of the property while exposing a property using an alternative representation.
• Insulating your public interface from change - allowing the public interface to remain constant while the implementation changes without effecting existing consumers.
• Controlling the lifetime and memory management (disposal) semantics of the property - particularly important in non-managed memory environments (like C++ or Objective-C).
• Providing a debugging interception point for when a property changes at runtime - debugging when and where a property changed to a particular value can be quite difficult without this in some languages.
• Improved interoperability with libraries that are designed to operate against property getter/setters - Mocking, Serialization, and WPF come to mind.
• Allowing inheritors to change the semantics of how the property behaves and is exposed by overriding the getter/setter methods.
• Allowing the getter/setter to be passed around as lambda expressions rather than values.
• Getters and setters can allow different access levels - for example the get may be public, but the set could be protected.

Answer 3

I am not a very experienced person to answer this question, even though I am trying to give my views and my experience by seeing source code which is around 10yrs older.

In earlier codes they were creating ivars and property/synthesise. Nowadays only property/synthesise is used.One benefit I see is of less code and no confusion.

Confusion!!! Yes, if ivars and its property are of different name, it does create a confusion to other person or even to you if you are reading your own code after a while. So use one name for ivar and property.

By using property KVO/KVB/KVC are handled automatically, thats for sure.

@property/@synthesise sets your ivar to 0/nil etc.

Also helpful if your subclass contains same ivar.

For mutable objects Dont make properties.