Should I Use self Keyword (Properties) In The Implementation?

Question

Hey guys. I believe I understand properties for the most part. My question is, if I have a property for an instance variable, and I am setting or retrieving it from within a method in my implementation file, should I use self.myProperty or just myProperty? I know either one works, but I have seen mixed conventions, sometimes code accesses the variable directly and other times through the property.

Is there a technical reason for doing this? Is it just convention/personal preference? And I'm not referring to the instances where the parameter name of a method collides with the instance variable name, which might be one reason to use the property (At least, in other languages, I don't know about this one). I assume that when one uses the property within the implementation, they want to take advantage of the way in which they declared the property (i.e. nonatomic, retain), so for example in a method, one can do:

self.myProperty = [someObject someAutoReleasedObject];

instead of:

myProperty = [[someObject someAutoReleasedObject] retain];

Is this the reason? So are there only certain situations in which it would be good to use the property?

I'm new to Objective-C, and this is one of the few things that has me confused. So far I've just accessed the instance variable directly, under the most likely false assumption that going through the property actually calls/sends a method/message and adds unnecessary overhead. I'm pretty sure I'm wrong with this, but even if the difference in overhead is negligible (If there even is any), why would one choose to add it in when one can simply directly access the variable?

Thanks! I'm pretty sure I'm wrong in my thinking, which is why I'm asking here, to learn the truth. I appreciate any responses :)

Answer 1

If you're exposing the property to the outside world and you're using it internally you should be using the property throughout your code. The reason is encapsulation. Say you have an "Id" property for SomeObj. Say at some point you decide to replace the way Id behaves (maybe you started with Id being a member var of the class, and through evolution it becomes a piece of data that is retrieved from the database). Now you have to go through your class implementation and replace all of the references to the member var with database calls. If you had self.Id, you'd just have to override the getter.

Answer 2

First, you should not use setters or getters in init or dealloc according to Apple documentation (and for good reasons).

Other than that, you should generally use the setter for setting the variable if there is one.

Usually I do not bother using the getter for accessing the ivar from within the implementation, but there are times when it is necessary. In particular, if you expect the getter might do some caclulation or checking, or if you want to allow for subclasses to override the behaviour.

Certainly, using the getter in the implementation is more general and safer, but it is also typically pointless and wasteful. Make your choice.

Using the setter is important as it gives an opertunity for other code to observe the changes (Key Value Observing), as well as subclasses a chance to override the setter and make any other adjustments required.

However one thing I highly recommend is to use a different name for your ivar and your property. The normal convention is an underscore prefix (_), although I personally use i_ as the prefix to avoid any confusion with Apple's private usage. That way you cannot accidently use the wrong one:

self.name // use property
i_name // use ivar
self.i_name // syntax error
name // syntax error