I want to understand when to use @property vs instance variables

Question

I've been learning Obj-C for a while now, and I have a fundamental question. There seems to be an inordinate number of 'self's everywhere in my code. I believe it is down to a basic question about the differences between two ways to declare and use variables.

Attached is some code that supports my question. In it, there are two variables declared (in different places) and used to do the same thing in a method: optionA and optionB. I am unsure which one to use. I thought it might be because using "property", as shown with optionB, would ensure that I get the accessors (setter and getter), but I see that optionA apparently has a setter.

I prefer optionA because it means I don't need "self" all over the place, but I want to understand the implications of using one over the other.

In a program I am working on, all variables are declared as properties (a la optionB below), but I have to use 'self' when accessing them. I am wondering if that is proper, and just an artifact of the right way to do things, or whether I am completely off the mark and should be using another form, like that of optionA.

When/Why would someone declare a variable between the curly braces of the interface (like optionA)?

I searched through the questions answered but don't find any that quite tell me what I am trying to learn here. But I can't quite find the info I am looking for in other questions or their answers.

I have a picture of the code here (but I don't have the prestige points to be allowed to link it directly into this message, apparently): http://i1127.photobucket.com/albums/l631/GenericImage/headerQueryOBJC.jpg

here are listings:

#import <Cocoa/Cocoa.h>

@interface AppDelegate : NSObject <NSApplicationDelegate> {
    IBOutlet NSTextField *optionA;

}

- (IBAction)happy:(id)sender; 
@property (assign) IBOutlet NSWindow *window; 
@property (weak) IBOutlet NSTextField *optionB; 
@end 

implementation

#import "AppDelegate.h" 

@implementation AppDelegate 
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification 
{ 
     // Insert code here to initialize your application 
} 


-(IBAction)happy:(id)sender
{  
    [optionA setStringValue:@":-)"]; 
    [[self optionB] setStringValue:@":)"]; 
} 

@end 

Answer 1

There are many scenarios where the use of a property is equivalent to the use of a variable.

In the scenario that you describe, where your variable & property refer to a user interface object (IBOutlet) and is linked to Interface Builder, you don't see that much the difference, mainly because your variable will point to the same object throughout the life-cycle of its owner (or controller, in apple's jargon)

Some of the things that can affect the scenario are:
- The use of ARC
- property modifiers (assign, copy...)
- bindings

If you use ARC it's more likely that you don't see clearly the difference. But when not using ARC, and having a property with 'copy' or 'assign' modifier allows you to see the difference.

@property (retain) NSString *string;

string = someOtherString;

In this example, prior to assigning someOtherString, the ivar associated to the property is released from its previous contents (and its retain count is decremented). If you were not using the property you would need to handle the retaincount yourself in each assignment, to avoid writing on deallocated memory.

Another example: if you use bindings in your projects, you will see that using ivars is not enough, because they are not KVC/KVO compliant.

Conclusion: If you understand the underlying concepts, you'll be able to know when properties and variables are equivalent.