Objective C's Instance Variables, why should I declare them?

I'm having a hard time understanding why I need to declare Instance Variables. Let me explain what I mean..

for example..

@interface LearningViewController : UIViewController {
  UILabel *myText; // <--- Instance Variables
}

@property (nonatomic,retain) IBOutlet UILabel *myText;

-(IBAction)method:(id)sender;

@end

this can also be done as

@interface LearningViewController : UIViewController {
  //instance variables go here, but are not declared, I just leave this field blank
}

@property (nonatomic,retain) IBOutlet UILabel *myText;

-(IBAction)method:(id)sender;

@end

as you can see.. in the latter example I ONLY built the setter / getter for the UILabel *myText

but in the former I declared the Instance Variables too.

Both end up working in the end

@implementation Learn开发者_如何学编程ingViewController

@synthesize myText;


-(IBAction)method:(id)sender {
  [myText setText:@"hey"];

  //or

  NSString *myObject = [[NSString alloc]initWithString:@"hey"];

  [myText setText:myObject];    
}

now both things produce the same result. So my question is, why? and what are the benefits of doing them either way? And why would I build and object

NSString *myObject = [[NSString alloc]initWithString:@"hey"];

myText.text = myObject;

when I can just do

[myText setText:@"hey"];

thanks in advance.

---

Also, there are times when you want to use a protected or private iVar within a class and not make a property out of it. (for example, when you don't want to allow access of an iVar to anything but an instance of this class (private) or its descendants (protected). Properties declared in the header are available to any object that can "see" the target object. Automatically declaring ivars in the header as properties (with or without the declaration inside the curly braces) might be bad from the standpoint of information hiding.

You can also add an implementation section to your .m file: any properties you declare there will be private to the class. The benefit (obviously) is both in achieving information hiding where needed, and the ability to use the dot notation.

---

Originally Objective-C did not have properties and @ synthesize did not exist. You had to declare your iVar (instance Variable) and write your own setters and getters.

When the language and runtime were revised to include properties and @synthesize, things were nicer. You no longer had to write your setters and getters. However you still had to declare your iVar.

Later still, the language and runtime evolved more and today, you don't even have to declare your iVar. (Although I tend to write @synthesize example = _example; so I can control what the generated iVar is named.)

This is a new feature and is only supported by relatively recent versions of the runtime. iOS versions less that 4.x are not supported, as are older versions of OSX.

If you are building software for today and the future, Go ahead and leave them out, If yot need legacy support, leave them in.

---

On the second part of the question, you are simply using the dot notation. You can set your myText.text equal to @"hey", the same way you are doing it in the second example.

[myText setText:@"hey"]; 

is synonymous to

myText.text = @"hey";

You don't need to declare an NSString to hold your value ahead of time.

---

You can leave iVars out, however I do not agree leaving out the iVars. The .h file in OOP is typically a header file that displays all variables and methods. It declares them. Assuming in the future you want to see what this class does, you just refer to the .h file. Or assuming someone else needs to look at that class, or use that class with his code to communicate with it. It makes it easier to look at the variables, see what is declared and what is not. That is, if you want to be programming professionally.

Now it really depends on what you want to do. The reason you would create an object is that so you are able to release it at a later time. So you continue to use it, and when you are done you just finish using it. Now creating instance variables for the whole class when they are just used in one method is not a good design decision. It is poor in a sense that the whole class is storing the variable, when in fact it is only used in one method. In this case, you should only create that object in that very method, and release it as soon as you're done with it.

Now sometimes doing

[myText setText@"hello"];

works. It really depends on your code. I guess the only way to really know the difference in situations is practice. Sometimes you need to set the label into another object, thus creating an object. Otherwise, it gets autoreleased etc...

Anyway, basically, use instance variables only for variables that are going to be used globally. And UI elements of course (since they are used by the whole class and interface builder).

Hope this helps.

---

As your code demonstrates, you don't technically need to declare instance variables, most of the time.

One critical exception to this is when you are compiling for the old (< 4.0) iOS runtime, as well as possibly the 32-bit Mac OS X runtime using GCC, which does not support the synthesis of instance variables.

Additionally, if you want to reserve space for later addition of instance variables (can be relevant if you are producing a framework and expect to extend a class at a later point), you'll need to explicitly declare the instance variables.

Edit: Long story short: Legacy, portability and extensibility concerns proscribe explicit ivars. For applications targeting 10.6, and especially 10.7, there is little or no need to declare them.