Question

There’s a lot out there on why to go through a @synthesized setter (instead of accessing the ivar directly), for retain/copy memory management, or for KVO.

But I can’t think of a good argument for why you’d care if you used foo = self.bar, or foo = bar.

The only thing I can think of is for data abstraction…if bar is a declared property, then the underlying implementation could change and no one else would care. (Of course, in this case, you’d probably not be using a @synthesized getter)

So…any compelling reasons to use @synthesized getters? Is there some threading issues that make it important?

For that matter, what does the @synthesized code even do, other than just return the ivar?

Answer 1

One good reason is encapsulation. When you go through the accessor, the class is free to do whatever tricks it wants behind the interface (as you already said in your question). The value may be fetched lazily, it might be computed on the fly or fetched from other object. That said, inside the class implementation I usually use the plain ivar access, as I am free to rewrite this if the property implementation changes. (This used to be a bigger issue when private ivars were declared in the public header, so that your subclasses could access them directly.)

As for threading, I think the default getter/setter combination is atomic, meaning that you can’t get a bug where the getter would be called in the middle of the setter, getting some invalid value. I’ve never read much into this issue, check out the documentation for the nonatomic property modifier. (Or this related question.)