Why should I use @properties?

Question

Possible duplicate:
What describes @property (...) best? What's that actually good for?

If I declare a variable in my class interface, I can use such a variable anywhere in my class. Tall.

If I use @property (retain) Something *myVar; I can access this variable using self.myVar ... But what is the difference? Is there a good reason why I should use this or that method?

Answer 1

Short answer: memory management encapsulation.

Longer answer: you need to establish ownership of the object if you want to use it later. If you want to use it later, you will need a link to it with which this is done, and a great place to save this link in an instance variable.

You can process ownership claims (i.e. save and release) every time you assign a new value, but that would leave a lot of repeating and erratic code patterns scattered everywhere, like cherries in a cupcake. This type of mess is terribly hard to debug when (and not if) something goes wrong. Thus, it is much better to wrap this code in accessor methods so that you can write it once and then forget about it.

But access methods are also mostly templates, so we use @property declarations to automatically create them, and not to write them manually.

Edit : The Apple Memory Management Guide contains a lot of detail about how access methods generated by @property are implemented behind the scenes.

Answer 2

If I use @property (save) something * myVar; I can access this variable using self.myVar ... But what is the difference?

 @property (retain) Something *myVar; // this property declaration declares: - (Something *)myVar; // and - (void)setMyIvar:(Something *)arg; // and is accessible by dot syntax. // it also declares and/or documents how the ivar is managed (copy, retain, etc.) 

in use:

 // direct access to the ivar. zero additional overhead (with regard to accessing the ivar) [myVar message]; // properties used with dot syntax invoke the accessor. therefore, [self.myVar message]; // is the same as: [[self myVar] message]; 

property properties also give instructions to the compiler on how to synthesize an accessor.

Is there a good reason why I should use this or that method?

in init and dealloc, access ivar directly - you are interested in initializing and clearing the ivars object and do not care about subclasses. using properties here can also lead to errors or undefined behavior.

for other cases, that is, when the object is in a fully constructed state, you should always use the accessory for consistency. if a subclass redefines an accessory, ivar direct access may disrupt the design.

if you want to avoid this, make ivar private and not declare a property for it. if you declare a property for it, then document its confidentiality; I usually write @property (retain) Something * private_myIvar; in this case. in this case it is convenient to use the property for synthseize ivar memory management.

when ivar is private, you have full access to it. safe to handle directly or privately. otherwise, suppose you must use an accessor.

if myIvar is declared private and will only be created upon initialization, you can not declare properties at all. this will reduce run-time overhead (if necessary). Message overhead, save / release cycles, and atomization (naturally) require longer execution times. therefore, it can be bypassed to increase productivity.

visibility / service. sometimes, it is much less maintenance / implementation to hide ivar from the interface. in other cases, ivar is a part of the class implementation and should not be part of the public interface. in such cases, consider making it private (there are several ways to account for this in objc).

Answer 3

Using @property to access your ivars does a lot of repeating code to release and save objects for you. You do not need to use them. It’s just a lot of tutorials that make it easy for people who are new to the platform.