51

Possible Duplicate:
Is there a difference between an "instance variable" and a "property" in objective-c / cocoa / cocoa-touch?

What is a case in Objective C where you would want to use an instance variable vs property? Can someone provide a real-life example?

Community
  • 1
  • 1
user472292
  • 1,069
  • 2
  • 22
  • 37
  • possible duplicate of [Is there a difference between an "instance variable" and a "property" in objective-c / cocoa / cocoa-touch?](http://stackoverflow.com/questions/843632/is-there-a-difference-between-an-instance-variable-and-a-property-in-objectiv) and http://stackoverflow.com/questions/719788 – Matt Ball Aug 14 '11 at 16:01

1 Answers1

98

An instance variable is unique to a class. By default, only the class and subclasses can access it. Therefore, as a fundamental principal of object-oriented programming, instance variables (ivars) are private—they are encapsulated by the class.

By contrast, a property is a public value that may or may not correspond to an instance variable. If you want to make an ivar public, you'd probably make a corresponding property. But at the same time, instance variables that you wish to keep private do not have corresponding properties, and so they cannot be accessed from outside of the class. You can also have a calculated property that does not correspond to an ivar.

Without a property, ivars can be kept hidden. In fact, unless an ivar is declared in a public header it is difficult to even determine that such an ivar exists.

A simple analogy would be a shrink-wrapped book. A property might be the title, author or hardcover vs. softcover. The "ivars" would be the actual contents of the book. You don't have access to the actual text until you own the book; you don't have access to the ivars unless you own the class.

More interestingly, properties are better integrated into the runtime. Modern 64-bit runtimes will generate an ivar for accessor properties, so you don't even need to create the ivar. Properties are in fact methods: 
// This is not syntactically correct but gets the meaning across
(self.variable) == ([self variable];)
(self.variable = 5;) == ([self setVariable:5];)

For every property, there are two methods (unless the property is declared readonly, in which case there is only one): there is the getter, which returns the same type as the ivar and is of the same name as the ivar, as well as the setter (which is not declared with a readonly ivar); it returns void and its name is simply set prepended to the variable name.

Because they are methods, you can make dynamic calls on them. Using NSSelectorFromString() and the various performSelector: methods, you can make a very dynamic program with many possibilities.

Finally, properties are used extensively in Core Data and with Key-Value Coding. Core Data is an advanced framework for storing data in a SQLite database while providing a clear Obj-C front-end; KVC is used throughout Core Data and is a dynamic way to access properties. It is used when encoding/decoding objects, such as when reading from XIBs.

Clay Ellis
  • 4,960
  • 2
  • 37
  • 45
FeifanZ
  • 16,250
  • 7
  • 45
  • 84
  • 11
    You can declare properties in a class extension to keep them "private" while benefiting of the memory management encapsulation and boilerplate code elimination that they provide. – albertamg Aug 14 '11 at 16:11
  • Yeah but what about ARC.. there's no more "memory management" needed, so is there still an advantage to use @property? – Van Du Tran May 24 '13 at 17:13
  • 2
    @VanDuTran: properties really aren't about memory management. They're 1/3 semantics, 2/3 functionality in terms of accessing values (and controlling that access). They also have runtime advantages, like I described in the second half of my post—you can't do that with ivars, because `@property` results in methods and the runtime system works with methods. – FeifanZ May 24 '13 at 17:19
  • 1
    iVars doesn't do retain unless you manually do it. Properties can retain it automatically. Your prog could crash if a method returns a pointers that needs expects you to retain it, but the method releases it after. – mskw Nov 20 '13 at 05:23
  • 1
    Indeed! Hence the need to set/get by calling '_property' instead of 'self.property' within certain methods, as this is often the cause of bad access errors you see occasionally. – Joel Balmer Dec 11 '13 at 10:53
  • 1
    arent properties declared in .m private too? – Esqarrouth Feb 16 '14 at 10:20
  • 4
    Yes. Properties/ivars have changed a bit since I wrote this answer…now all properties come with implicit ivars (`@property var` also makes available the the ivar `_var`). Properties declared in the `.m` is now the 'best' way to create a private field – FeifanZ Feb 16 '14 at 14:24
  • @FeifanZ, So should one use ivars anymore in 2015? – Iulian Onofrei Apr 14 '15 at 13:30
  • 1
    @IulianOnofrei AFAIK, with Swift you can't create an ivar without it being a "property" as well. With ObjC, there is no "should" or "shouldn't"; the reasons for either stated above are still valid, and it depends on how you want your code to work. – FeifanZ Apr 14 '15 at 14:55
  • 1
    Refer this :- http://www.onestopios.com/tutorials/understanding-instance-variables-properties/ – Ashish P May 15 '15 at 17:53
  • 1
    Excellent answer this answer is better than answers on the other question. AFAIK you are wrong about ivars in .h . They are accessible from outside of implementation. See http://stackoverflow.com/a/36577175/5175709 and kindly let us know what is right. – mfaani Apr 12 '16 at 15:41
  • Why that `is not syntactically correct but gets the meaning across`? I thought `self.variable` and `[self variable];` are just equivalent? – allenlinli Jan 07 '19 at 01:33
  • @Clay what if I set my instance variables (ivars) public? then what's the purpose of @property? – Raja Saad Feb 11 '21 at 14:11