Why is everything a property in iOS SDK tutorials?

In most of the iOS SDK tutorials I've read online both from Apple and elsewhere, so many instance variables are made properties, even when they are only accessed from within their own class.

E.G. in Facebook's latest iOS SDK a user is encouraged to maintain an instance of the Facebook class called facebook in the app delegate. facebook" is a property. This is then referred to throughout the sample code as "self.facebook". But the "facebook" property is not referenced anywhere from outside the app delegate.

Why is this? What am I missing? If an instance variable is only used within its own class, my inclination would be not to make it a property so that it is not publicly visible, and refer to it simply as facebook rather than self.facebook or self->facebook from within the class.

Frankly, even if I needed the facebook property, I think I'd rather refer to it within the app delegate as simply "facebook" rather than "self.facebook"开发者_如何学运维.

So what gives? Why am I seeing properties everywhere?

Properties don't have anything to do with whether an iVar is publicly exposed or not. Instead properties create accessors methods that manage retention and foster encapsulation.

If you want a private property just declare the ivar under the @private directive and then define the properties in the implementation file.

One great example of why you should use properties (you can make properties private as TechZen noted), is creating new instances in viewDidLoad.

People do this all the time, because it's called once per instance of a view controller. Or, so you think... in reality because of what happens when you application gets a memory warning, a viewDidLoad class could be called multiple times per instance.

So for example you might well write code like:

- (void) viewDidLoad
{ myArray = [[NSMutableArray alloc] init]; }

Works great - until it's called again, then you have a leak. You could release myArray before you assign it just in case - but the trouble is that's an easy step to forget.

If you use properties for every instance variable though, then your code looks like this:

- (void) viewDidLoad
{ self.myArray = [NSMutableArray array]; }

Now you can't get it wrong. If viewDidLoad is called multiple times, the old array will be released and a new one will go in its place, without leaking the old array.

Usually it's better to access to the instance variable through an accessor, rather than directly. Properties create these accessors, and also provide things like proper key-value change notifications and atomic access.

Properties can generate getters and setters. Setters, in particular, can help manage retain/release counts of objects (semi)automatically, and thus reduce certain types of potential memory bugs.

Getters and properties for non-objects are mostly for orthogonality of coding style, although they do have potential to be used for mutators, key-value notifications, etc. in some future extension or reuse of the code.

There may be some efficiency differences/disadvantages, but that depends on the particular ObjC run-time in use.

if you refer to facebook, then it will access the variable directly, if you access self.facebook, then it will go through the setter/getter methods.

the result is that if you need to mutate an object or at somepoint later in time, you need to do other things during the process of changing the value(ie boxing it) then you can put this in the setter method and reduce having to do it everywhere. its a good thing.

It creates the getter/setter for you automatically. Also, here is a good post explaining it properties