views:

455

answers:

3

In objective c, if the using the getter and directly accessing the ivar do exactly the same thing, no lazy loading code in the getter, all it does is returns the ivar, would you still use the accessor or access the ivar directly since there is no difference? Why?

EDIT: I'm talking about inside the class.

A: 

Are you talking about outside of the class, or within? If without, then you always use the accessor. First of all, the default visibility for ivars in ObjC is @protected, so unless you explicitly make them @public, you have to use an accessor. Aside from this, you use the accessor because you never know if you (or someone else) might subclass your class and change it enough that using the accessor is necessary.

If you're talking about within the class, you don't have to use the accessor, but if you set up @property values, there's no reason not to use the dot notation, even if you're synthesizing everything. If you're using standard ObjC notation, such as [myObject someVariable], then repeated nested messages can get hard to read and cluttered.

Really, the accessor isn't as big a deal as the mutator, because mutators often do more than one thing. Using both getters (outside the class) and setters is good practice.

Cinder6
I'm talking about inside the class.
Mk12
"If you're talking about within the class, you don't usually use the accessor, unless there's some specific (present or future) reason to do so.".........."Using both getters and setters is good practice." So what is your answer (within the class) ? You seem to say not to use it and then say its good to use it..
Mk12
I've never seen anyone arguing for using the accessor within the class, unless there's a specific reason to (and the last class I took spent over a week going over *why* you use the getters and setters in the first place).On the other hand, there's nothing *wrong* with using it in the class. Pick one way, and stick to it.
Cinder6
My advice is to use the accessor properties. This will save you the effort of combing through your code if you actually have the accessors do more work than just get and set the member variable, such as if you need to lazily load things. using the accessors in the class for the most part can make things simpler in that instance.
Kevlar
I somehow forgot we're on ObjC 2.0 now--if you set up @property values, there's no reason *not* to use them, even if they're all synthesized.
Cinder6
I always use accessors inside the class. It keeps the responsibility of memory management within one method. Otherwise you have to repeat it and repeat it and...
Chuck
I don't find the nested bracket notation hard to read, I think it makes the look of the code flow nicely. I still can't decide on using the getter.. I prefer explicit over implicit, and the using the property makes it explicit that it is an ivar, but I don't know..
Mk12
@Mk12: I don't see how using a property makes it any more explicit that it's an ivar than using a method. Properties are just syntactic sugar for accessor methods. Which means that it's possible to have a property with no underlying instance variable just as you can have an method that returns something other than an instance variable.
Chuck
I'm talking about using the [self ivar] vs just ivar. I know they're just methods... The main point of properties is for classes outside to access private/protected ivars, right?.. All this whole question ever was was deciding whether to always use the accessors or not.
Mk12
Just writing the name of an ivar does not use a property. You have to write `self.propertyname` in order to go through a property, which may or may not be named the same as an ivar.
Chuck
I never said ivar uses the property.
Mk12
+4  A: 

There is a small performance advantage to be enjoyed by using the ivar directly. However, to avoid confusion, I typically prefix my ivars with _ on the front, and then synthesize a property using @synthesize foo = _foo; which means I can either do [self foo] or _foo. It then becomes clearer in the code which I'm referring to.

However, the advantage isn't much, and some might argue that this is premature optimisation. What using the property (or method) will give you is the ability to evolve your class later and change the ivar but whilst keeping the property the same (e.g. making it a calculated property). It will also allow subclasses to override your property and still work.

(By the way, there are still some cases where referring to property syntax can be helpful, such as when writing to the ivar. In this case, the property support for copy|retain can be helpful in freeing up the previous object and getting the right sequence of retain/release calls)

AlBlue
I think this is a good practice, I do it myself. Timesaver for sure.
Sneakyness
Is there really any performance difference between using ivar directly and calling a method that does nothing but returns ivar?
Mk12
Is there a performance difference? Yes. Is it significant? No.
AlBlue
A: 

I decided to always use the [self ivar], not directly ivar, even though I use standard ObjC bracket notation , not dot notation. Only exception is if [self ivar] is a lazy-loading accessor and I already used it in the method and I know it has been initialised and I don't want to check if it is nil the 10 more times I use it in the method.

Mk12