Should I declare variables in interface or using property in objective-c arc?

fmchan picture fmchan · Jan 9, 2013 · Viewed 11.1k times · Source

approach 1:

@interface MyController : UIViewController {
    UILabel *myText;
}

@property (nonatomic, strong) UILabel *myText;

approach 2:

@interface MyController : UIViewController
@property (nonatomic, strong) UILabel *myText;

approach 3:

@interface MyController : UIViewController {
    UILabel *myText;
}

I have read some articles talking about this kind of stuff but I still do not really realize which approach I have to adopt.

I also found that someone said approach 1 is a old way so I would like to know the best practice for ios sdk 6 using ARC.

I know that declaring variables using property is a easy way for generating getter and setter and someone suggested using it. However, I would like to ask in case a variable is not for calling by another class, is it necessary for the variable using property? and set it as private variable inside the interface? Or is it better for a variable only declaring inside the interface? I would like to learn the best practice so please forgive me if this is a silly question.

Moreover, some developers write @synthesize in this way

@synthesize myText=_myText;

but some write this:

@synthesize myText;

I would also want to know the difference and which one is preferable?

Thank you very much!

Answer

foundry picture foundry · Jan 9, 2013

The most modern way1:

  • whenever possible, declare properties
  • don't declare iVars separately 2
  • don't @synthesize 3
  • locate as few properties as possible in you .h file 4
  • locate as many properties as possible in a class extension in your .m file 5

1 As of Xcode 4.5.2. Most of this applies back to 4.4, some of it won't compile on 4.2 (the last version available under Snow Leopard). This is preprocessor stuff, so it is all compatible back at least to iOS5 (I haven't tested on iOS4 but that should also be OK).

2 There is no point in declaring an iVar as well as a property. I am sure there are a few obscure cases where you would want to declare iVars instead of properties but I can't think of any.

3 Xcode will create an iVar with the same name as the property, preceded by an _underscore. If you (rarely) need some other kind of behaviour, you can manually @synthesize property = someOtherName. @vikingosegundo links us to this article on dynamic ivars, which is a use case for @synthesize. @RobNapier comments that you do need to @synthesize iVar = _iVar (bizarrely) if you are creating your own getters (readonly) and setters (read/write) for a property, as in this case the preprocessor will not generate the iVar for you.

4 The general rule with your interface: keep it as empty as possible. You don't actually need to declare your methods now at all, if they are for private use. If you can get the code to work without an interface declaration, that's the way to go.

5 This is an @interface block in your .m file, placed above your @implementation:

#TestClass.m

@interface TestClass()

//private property declarations here

@end

@implementation TestClass
...