Question

Possible Duplicate:
Is there any reason to declare ivars if you're using properties exclusively in Objective-C?
ObjectiveC ivars or @property

I am new to iPhone programming (and the programming scene altogether). I have tried to study about Properties at various places and found out that they are basically the shortcut to making getter and setter methods for other classes to get access to those objects.

Now, I have seen programmers define the object in the curly braces after the @interface:UIViewController as well as in the properties after that when all the accessing will happen within that class’ .m file.

Now, that superfluous (?) piece of code, is it necessary? Is this a standard? Looking forward to some intelligible opinions.

Thank you in advance.

Answer 1

I can interpret your question in a number of ways:

Question: Why do some programmers use properties and instance variables (the variables defined within the curly braces), and others just use properties, and other just use instance variables?

Answer: As you know, @property declarations will, when you @synthesize them, will generate the getters and setters for you. Historically, this is all that it did for you and you had to also manually declare your instance variables. Later, the compiler was improved so that if you didn’t have the instance variable defined, that the @synthesize statement would generate that, too. When this was first introduced, common practice was to define both the property and the instance variables, but Apple eventually shifted their guidelines and encouraged programmers to not define instance variables, but let the compiler generate that itself from the @property and @synthesize declarations.

So, in answer to your questions: 1. defining instance variables for your properties is now superfluous; 2. it is no longer necessary; and 3. it is now standard to not explicitly declare instance variables, but rather to let the @synthesize statement do that.

As an aside, the convention on the @synthesize statement is to, with an property called var, to precede the instance variable name with an underscore, thus @synthesize var = _var. This is done to minimize the chance that a programmer might accidentally refer to an ivar when the property was intended (or vice versa). To further illustrate that this is the preferred standard, starting in Xcode 4.4, even the @synthesize statement is optional (thus, define the @property, but no ivar, and no @synthesize) and it will declare and ivar the same name as your property, except with a leading underscore.

Question: Why do some programmers define some of their properties and instance variables in the .m file? Why do other programmers declare some of their instance variables and properties in the .h file when they’re only being used within the class’s own .m file.

Answer: Those instance variables and properties defined within the .m file (in what is called a class extension) are just a convenient way of defining those ivars/properties that are not advertised to the world. In this convention, your .h file becomes just your public interface (what properties and methods can be invoked from elsewhere) and everything else goes in the .m file. It’s a nice way to keep your interfaces a little cleaner so when you go to use your class at some future date, you can just look at the .h file and not get too lost in the details of the class’s implementation details.

In the past, before class extensions became prevalent, we defined all of our instance variables and properties in the .h file, even if they were private and used only within the class’s own .m file. Thus, you’ll still see some code that does this.

So, in answer to your questions, 1. it’s not superfluous to use class extensions (unless your class extension is empty, but even then I tend to keep it so I can see that there are no private ivars/properties); 2. the use of class extensions is not necessary; but 3. the use of class extensions for private properties/variables that are used only within the class itself is an emerging standard and probably does represent best practice.