12

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?

trapper
  • 11,716
  • 7
  • 38
  • 82

5 Answers5

31

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.

bbum
  • 162,346
  • 23
  • 271
  • 359
  • 6
    Also properties also make it easier and safer to add copy semantics and atomic semantics. Plus creating a property with one name and a instance variable with another using @synthesize propname = ivarname; is always useful. – Cthutu Mar 26 '12 at 17:42
  • Agree, thanks for the answer. I'd also like to add that there's a lot of talk out there about @property performance vs ivars. I dare you to find a performance difference between a nonatomic property and an ivar... it's probably immeasurably negligible. – Amir Memon Aug 20 '13 at 20:26
  • 1
    Wouldn't you also agree that the modifier keywords weak, strong, atomic etc are useful flags for you in your api and also for arc itself to understand your intent ? – Jef Feb 23 '16 at 00:52
6

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.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
2

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.

Kevin Low
  • 2,672
  • 16
  • 17
  • If you haven't been using properties, you've probably been doing it wrong. “Sometimes it might seem tedious or pedantic, but if you use accessor methods consistently the chances of having problems with memory management decrease considerably. If you are using retain and release on instance variables throughout your code, you are almost certainly doing the wrong thing.” — Memory Management Programming Guide, Apple – Dave Batton Apr 24 '12 at 23:39
  • @DaveBatton that quote doesn't apply to ARC – Jesse Gumpo Aug 02 '12 at 20:28
  • @JesseGumpo Agreed, it doesn't apply to ARC. I intended for it to apply to Kevin's comment that he's never "used properties simply because of memory management..." – Dave Batton Aug 02 '12 at 21:02
1

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.

Gobot
  • 2,464
  • 1
  • 21
  • 26
0

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).

Greg
  • 8,230
  • 5
  • 38
  • 53