2

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?

wrjohns
  • 484
  • 4
  • 14

2 Answers2

2

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.)

Community
  • 1
  • 1
zoul
  • 102,279
  • 44
  • 260
  • 354
  • Your lazy loading example though would require a custom getter...not a @synthesized one. I can certainly see a need for custom getters. The thread safety point is a good one. – wrjohns Jul 31 '12 at 12:05
  • 1
    The point is that if you don’t use the synthesized getter now and use direct ivar access instead, you can’t change the implementation later (by adding lazy loading, for example) without rewriting all the accesses to the ivar. This might be a problem if the direct ivar access leaked to your subclasses or even your API users. – zoul Jul 31 '12 at 14:01
1

The getter also needs to conform to the memory management rules defined in the @property statement; for example if it has the retain attribute it needs to use autorelease:

- (NSString *)name
{
    return [[_name retain ] autorelease];
}

And having it synthesised saves you from having to type it out. Plus being able to synthesise both getter and setter is a more complete solution.

trojanfoe
  • 120,358
  • 21
  • 212
  • 242
  • 2
    It is `[[_name retain] autorelease]` – hamstergene Jul 31 '12 at 06:53
  • @hamstergene Thank you - still on my first cup of coffee – trojanfoe Jul 31 '12 at 06:54
  • 1
    Just a note: The "memory management rules" argument does not apply if you compile with ARC. `foo = bar` will always "do the right thing". – Martin R Jul 31 '12 at 08:08
  • @MartinR That is true, however the OP doesn't tell use whether he's using MRR or ARC. – trojanfoe Jul 31 '12 at 08:13
  • I usually use MRR. And I'd still go ahead and generate the synthesized getter (and setter), but say with primitive data types, does it matter if you just access the ivar directly, especially from within the class's own methods? – wrjohns Jul 31 '12 at 11:55