37

I want to define private instance variables in MyClass.m file. It seems to me there are two ways to do it:

  1. use class extension

    @interface HelloViewController ()
    {
         int value;
    }
    
  2. define in @implementation section

    @implementation HelloViewController
    {
        int value;
    }
    

Which is better?

I think recent Apple's coding style is to use class extension?

e.g. MasterViewController.m generated by 'Master-Detail Application Template'

@interface MasterViewController () {
    NSMutableArray *_objects;
}
@end
Makoto Otsu
  • 379
  • 1
  • 3
  • 4
  • 1
    Why do you need private instance variables instead of private properties? – Anurag Nov 23 '12 at 16:48
  • In the @implementation of course - less typing! – Peter M Nov 23 '12 at 16:50
  • possible duplicate of [How to declare instance variables and methods not visible or usable outside of the class instance?](http://stackoverflow.com/questions/5826345/how-to-declare-instance-variables-and-methods-not-visible-or-usable-outside-of-t) – Max MacLeod Nov 23 '12 at 17:24
  • @PeterM Doing it in the implementation means you can't set the property to be readwrite/readonly, atomic/nonatomic, and strong/copy. Can't see how that's better. – Boon Jun 01 '15 at 13:23

3 Answers3

58

The "Modern Objective-C" way to do this is to declare them in your implementation block, like this:

@implementation ClassName {
    int privateInteger;
    MyObject *privateObject;
}

// method implementations etc...

@end

See this earlier post of me with more details.

Community
  • 1
  • 1
DrummerB
  • 39,814
  • 12
  • 105
  • 142
  • I can't find anywhere in Apple doc where it recommends that this is the better approach. – Boon Jun 01 '15 at 13:17
  • Doing it in implementation has the disadvantage that you can't specify property attribute such as nonatomic, copy, etc. – Boon Jun 01 '15 at 13:21
  • @Boon That doesn't depend on where you declare it, but whether it's a plain ivar or a property. – DrummerB Jun 02 '15 at 14:20
  • Sorry for the lack of clarity, yes that's what I meant. Doing ivar has the disadvantage that you can't specify strong/copy, etc. So you have to remember to call copy on an array. 99% of Apple sample code uses property rather than ivar. – Boon Jun 02 '15 at 15:03
8
@interface HelloViewController ()
{
    @private     //optional, this is old style
    int vale;
}

If you were making a library, though, theoretically no one would know about any methods you didn't declare in the header files.

Copied from: How to make a real private instance variable?


Declaring instance variables in the @implementation is a recent feature of Obj-C, this is why you see a lot of code with them in the @interface - there was no other choice.

If you are using a compiler which supports declaring instance variables in the implementation declaring them there is probably the best default - only put them in the interface if they need to be accessed by others.

Instance variables declared in the implementation are implicitly hidden (effectively private) and the visibility cannot be changed - @public, @protected and @private do not produce compiler errors (with the current Clang at least) but are ignored.

Copied from: Private ivar in @interface or @implementation

Community
  • 1
  • 1
Anoop Vaidya
  • 46,283
  • 15
  • 111
  • 140
0

In my view the best is to define it like private properties that you can access as fields or properties just within your implementation, the advatage is that you can access them by self as well as by _fieldName syntax what is handy in some situations.

@interface SignUpController ()
@property ViewHeaderView*header; //private properties/fields
@property UITextField*activeField;
@property CGFloat keyboardHeight;
@end

@implementation SignUpController {

}

@end
Renetik
  • 5,887
  • 1
  • 47
  • 66