Should I use properties or direct reference when accessing instance variables internally?

Question

Say I have a class like this:

@interface MyAwesomeClass : NSObject
{
@private
    NSString *thing1;
    NSString *thing2;
}
@property (retain) NSString *thin         


        

Answer 1

I don't think any way is 'better'. You see both styles in common use, so there isn't even a usual/best practice now. In my experience, the style used has very little impact on how well I digest some implementation file I am looking. You certainly want to be comfortable with both styles (and any in between) when looking at other people's code.

Using a property for every internal ivar might be going slightly overboard, in terms of maintenance. I've done it, and it added a non-trivial amount of work that I don't think paid off for me. But if you have a strong desire/OCD for seeing consistent code like self.var everywhere, and you have it in the back of your mind every time you look at a class, then use it. Don't discount the effect that a nagging feeling can have on productivity.

Exceptions- Obviously, for custom getters (e.g. lazy creation), you don't have much of a choice. Also, I do create and use a property for internal setters when it makes it more convenient (e.g. setting objects with ownership semantics).

"just in case", "might" is not be a compelling reason to do something without more data, since the time required to implement it is non-zero. A better question might be, what is the probability that all the private ivars in some class will require KVC notifications in the future, but not now? For most of my own classes, the answer is exceedingly low, so I now avoid a hard rule about creating properties for every private ivar.

I've found that when dealing with internal implementations, I quickly get a good handle on how each ivar should be accessed regardless.

If you are interested, my own approach is this:

• Reading ivars: Direct access, unless there is a custom getter (e.g. lazy creation)
• Writing ivars: Directly in alloc/dealloc. Elsewhere, through a private property if one exists.