With ARC why use @properties anymore?

Question

In non-ARC code retained properties handily take care of memory management for you using the self.property = syntax, so we were taught to use them for practically everything.

But now with ARC this memory management is no longer an issue, so does the reason for using properties evaporate? is there still any good reason (obviously other than providing public access to instance variables) to use properties anymore?

Answer 1

I don't think I've ever used properties simply because of memory management and I don't think you ever should. So to answer your question, no, there's no reason to use properties other than to access instance variables, which is essentially what they're supposed to be used for in the first place.

Answer 2

You are talking about two different things. ARC is for managing memory, so you don't have to be burdened with an abundance of dealloc and retain statements.

Properties are there to give a class the opportunity to control/limit exposure of its internal iVars, exposing an API for other classes to communicate/interact with.

Answer 3

Apart from retained there are also other modifiers that on occasions may become quite useful, e.g. 'copy' when assigning blocks to class member variables, or 'readonly' which ensures the property can't be written to. Also don't forget about 'dynamic' properties when working with Core Data, and the possibility to execute custom code when assigning or retrieving a property (when defining custom getters/setters instead of using @synthesize).

Answer 4

But now with ARC this memory management is no longer an issue, so does the reason for using properties evaporate? is there still any good reason (obviously other than providing public access to instance variables) to use properties anymore?

Yes -- by using @property and @synthesized getters/setters, you guarantee that:

• your getter/setter can be subclassed and subclasses can override storage and/or behavior
• everything remains nicely encapsulated
• you can use observation hooks -- KVO, etc... -- to monitor changes internally and externally
• you have a convenient spot to set a breakpoint on read and/or write to the property
• if that "internal only" instance variable were need to be exposed, it is a matter of copying the @property declaration itself; much less refactoring.
• you can leverage the declarative power of all the various modifier keywords -- copy, strong, weak, atomic, etc.. -- which the compiler is taking more and more advantage of over thime

Even internally to a class, I generally lean to using properties and dot syntax to maintain state within the object. That isn't universally true -- there will be some instance variables that I directly manipulate (exclusively directly manipulate; no @property at all) if my design is such that exposure would imply a massive refactoring anyway.

Answer 5

so does the reason for using properties evaporate?

With ARC making the "ownership magic" available to ivars, this particular aspect of why one would choose properties over ivars does evaporate. However, many others remain:

• atomic/nonatomic distinction is available for properties, not for ivars
• flexibility afforded by properties (readonly/read+write distinction) is not available for ivars
• ability to perform calculation and argument checking is not available to ivars

I continue using properties as my default way of keeping state that may be exposed to outside classes or internal "sibling" classes, because additional flexibility more than outweighs the small additional cost at run-time.