Objective-C: do you use the @private visibility / access modifier in your code?

Question

There are 3 modifiers: @private, @protected (by default) and @public. Being used to it in C ++ and other more reasonable languages, I always use @private for my fields. I hardly (if ever) see Apple’s SDK examples - they just rely on the standard version.

One fine day, I realized that Objective-C inheritance is a pretty fake feature: getting an interface from another doesn't mean that all private fields are now available for redefinition. The compiler still sees them and forbids defining a new private field with the same name, which goes orthogonally with the classical encapsulation paradigm in OOD.

So I'm a little upset. Perhaps I expect too much from the language because it is nothing more than a creation over the C standard.

So, are you using @private in your code? Why?

Answer 1

I think it’s a good idea to always use @private, but I never worried about the past, because I usually use property accessors for almost all ivar access except methods initand dealloc. Therefore, in practice, I rarely have the problem of accessing ivars by mistake.

Also, if you configure iOS 4+, you do not need to declare ivars for properties if you use @synthesize.

---

, , , @private .

Answer 2

, , , agianst, , .

@private ( obj->_ivar, [obj getter] obj.getter). , , - , , - NSCoding NSCopying, , .

Answer 3

This is really useful for Apple or people who ship libraries who want to expose certain fields only to themselves in header files. We never use it, because the accessory model allows you (or not) to show what you want. Since I have both header and source files, which is really good? Objective-C is not C ++, so @private has a different purpose.

Answer 4

In all the code I've written in Objective-C since 1989, I never bothered to use @public, @protected or @private.