why to declare some instance variables as properties

Though this is somewhat a very basic question but I have some doubts still left after reading so many documents and questions on stackoverflow.com.

I want to know why to declare some instance variables as properties.

MYViewController.h
   @interface MyViewController : UIViewController {
        UIButton *btn;
        NSString *name;
    }
    @property (nonatomic, retain) UIButton *btn;
    @property (nonatomic, retain) NSString *name;

MyViewController.m
   @implementation MyViewController
   @synthesize btn;

-(void) viewDidLoad()
{
   [btn setTitle:@"Hello" forState:UIControlstaeNormal]; //this is first way where there is no need to declare btn as property

   [self.btn setTitle:@"Hello" forState:UIControlstaeNormal]; //this is second way where we do need to decalre btn as property as we are accessing it through self 


//Setting value of name

  name = @"abc"; //this is first way where there is no need to declare name as property 
  [self setName:@"abc"; //this is second way where we do need to declare name as property as we are accessing its aetter method thro开发者_开发知识库ugh self

}

Now in the above code I wanna know when we can use the getter/setter methods of btn variable without declaring it as property then what is the need to declare it as property and which is the better way to set the value of "name".

Somewhere I read that when you want your instance variables to be accessed my other class objects then you should declare them as instance variables. Is it the only situation where we should declare them as properties.

Basically I am a little confused about in which situations to declare the instance variables as properties.

Please suggest. Thanks in advance.

In short, you don't have to declare instance variables as properties unless you want to. You declare a variable as a property in order to auto-generate getter and setter methods. In your property declaration you can specify how you want them set up (retain vs assign, atomic vs nonatomic). Then, the getter and setter are generated with the @synthesize directive. So, again, there is no right or wrong way to use properties. Some people never use them, some people make every variable a property. It's really up to you.

typically, you'll use them because:

1) the property belongs in the public interface of the class

used when the class needs to expose a given method. the downside is that clients and subclasses may abuse the public interface (all objc methods are public, where visible), unless you're careful to hide these details (which is also a pain at times). sometimes you're forced to go well out of your way in order to achieve the class interface you need (with the proper levels of visibility).

2) you want auto-generated accessors

implementing nonspecialized accessors is tedious, and error prone. it's better to save the time and let the compiler generate them for you.

3) to document behavior

sometimes it's better to write @property (copy) NSString * title; instead of over-documenting the expected result.

4) stricter selector matching with dot-syntax

the compiler performs stricter selector matching. prefer to catch the errors/issues at compilation, if possible.

5) to force the subclasses to use them instead of handling the ivars directly

objc ivars are protected by default. you'll often want them to be private (depending on how the class is used and distributed, or just to ensure the subclass uses the base class correctly).

there are a ton of reasons for this. threading and maintenance are the big ones.

if you declare the ivar as private and provide a property for the subclass to use, then the subclass is forced to use the property in their implementation (although there are ways they could cheat) rather than giving them direct access to the ivar.

so... it ultimately depends on your preference, and the implementation details of your class, paired with the interfaces you're using. i don't think there's a hard and fast rule here - lesser evils and convenience are key motivations.