Case for using properties in Objective-C

Question

The documentation for the OS X 10.8 Core Library in the section "Programming with Objective-C" states

"It's best to use a property on an object anytime you need to track a value or another object. If you need to define your own instance variables without declaring a property, you can add them inside curly brackets at the top of the class interface or implementation ..."

So, I'm curious that there will be times when you need to define instance variables without declaring properties? Besides what the apple says, can this be just a personal preference?

Thanks!

Answer 1

Some of them are definitely a matter of preference, but not all: you are better off having a property for items with external visibility and items that require different access controls inside and outside your class. The question was much less pronounced after the introduction of ARC, because before it you can use properties for automatic save and release calls. The value of this aspect of properties has diminished significantly in situations where you need to automatically copy objects to your property.

Answer 2

If you use ARC and a recent working environment (recent enough for you to declare your ivars in the @implementation block), the instance variables suddenly become unexpected. What for? Since unlike @properties they belong to the class. There is no risk that they will be accidentally overridden by a subclass.

They are also faster in the simple case, since you do not call any methods to get or set them.

I personally find it cleaner. There are no more class extensions defining private @properties, and all this is undesirable. Just Ivars, beautiful and simple.

Therefore, the best advice, IMHO, is to use them by default. Use @properties only if you really need their functionality, for example:

• You need a way to access them from outside your class.
• You want subclasses to overlap them.
• Your getter or setter is more than just a trivial assignment.

The last two are less common than you think. It is generally not wise to try to override properties in subclasses, simply because it is a bit unusual and there are some rough edges.

If you later find that you need to upgrade ivar to @property, it’s nice and simple - the only place it can be accessed is in your @implementation, so it usually is a simple search and a replacement to add “I”. to its links (and possibly remove the leading underscore if you name them that way). 'til then you do not need to pay expenses and manage the risks of using @properties.

Answer 3

I prefer properties because I can define setters / getters and because I like this syntax more.
Many people claim that it is bad practice to use Ivars, as in this article:
http://cocoasamurai.blogspot.it/2012/08/cover-up-those-ivars.html
Unfortunately, programmers today call bad practice something they don’t like, even without objective reasons.
If you declare ivar, you can still use the @private directive, so this is not a matter of expanding or missing variables. I think that if you like more Ivars, you should use them.