4

I have thought of different ways of declaring private variables. I want to know whether there are any differences between them.
First way:

//In .h file
@interface DataExtract : NSObject
{   
    @private
    double test;
}

Second way:

//In .m file. test is not declared in .h file
static double test;

Third way:

//In .m file. test is not declared in .h file
double test;

Any help would be much appreciated. Thank you.

CodeHelp
  • 1,328
  • 5
  • 21
  • 37

4 Answers4

5

You can declare a private @interface in the .m file.

//DataExtract.m

@interface DataExtract ()
//your variables
@end

@implementation DataExtract

@end

For more info you can go here

Community
  • 1
  • 1
Maximilian Liesegang
  • 974
  • 5
  • 13
  • ...however this won't compile for OSX 32-bit due to runtime restrictions. – trojanfoe Sep 06 '13 at 08:01
  • @Hemant Again you have already posted your link 3 times in the comments, why have you edited this answer to include your answer? If you have an answer please give your own answer don't edit someone elses to include yours. – Popeye Sep 06 '13 at 08:10
  • Downvoting because (while your answer is in itself correct) you don't point out the glaring misunderstanding of the OP. – Nikolai Ruhe Sep 06 '13 at 08:10
  • Actually i am trying to post this as answer but my answer is posted as comments. – Hemant Singh Rathore Sep 06 '13 at 08:13
  • @Hemant instead of using the comments box use the answer box at the bottom of the page. – Popeye Sep 06 '13 at 08:16
5

Your second and third examples are not instance variables, but global variables (with differing scope) and the same value will be shared across the entire process.

trojanfoe
  • 120,358
  • 21
  • 212
  • 242
5

All of them are not a good solution if you want an ivar. I would even tend to only use properties with autogenerated ivars in an class extension in the implementation file only one line (@synthesize is automatically generated in Objective-C 3.0).

First way:

Yes this is an ivar, but you shouldn't declare it in the header file, if you declare it @private, then use the @implementation {...} block. In the implementation block you don't need to declare it @private, because it defaults to @protected, but in the implementation block it is not visible for subclasses

Second way:

That is a variable only visible in the translation unit, here the .m file itself. It is not global for the whole app. The value is persistent for every instance of your class, so it is no ivar (instance variable).

Third way:

That is also no ivar, it is a variable which defaults to extern, because you did not write static. That means it is in the global symbol table and can be used in other translation units /files if they #import/#include the .m file.

Binarian
  • 12,296
  • 8
  • 53
  • 84
1

Is there a reason you want to use just an instance variable, instead of a property?

You can declare a private property like so:

// Private Interface in .m file
@interface DataExtract()

@property (nonatomic) double test;

@end

Edit: If you do want to use a private ivar, instead of a property, you could do it like so:

// Private Interface in .m file
@interface DataExtract() {
    double test;
}

@end
JoeFryer
  • 2,751
  • 1
  • 18
  • 23
  • There can be many reasons to use an instance variable instead of a property. The question is about how to define ivars. – Nikolai Ruhe Sep 06 '13 at 08:43
  • I would not say there are *many* reasons to use an ivar over a property at all. Anyway, I've edited my answer to include how to do this. – JoeFryer Sep 06 '13 at 09:07
  • I disagree with your assertion "generally a property is the 'better' way to go". Properties and ivars serve a different purpose or role in a class's design: A property is part of the API of a class. While not always publicly visible it interfaces with outside stuff. An ivar defines the encapsulated inner state of an object. – Nikolai Ruhe Sep 06 '13 at 09:20
  • We can agree to disagree, but why the down vote? My advice (that *generally* a property is the 'better' way to go), I believe, is in-keeping with the generally accepted view on the subject. – JoeFryer Sep 06 '13 at 10:08
  • No, that's exactly what I'm opposing. As I said, ivars have their place. If a part of an object's state is private that piece should not be exposed. Don't over-use properties. – Nikolai Ruhe Sep 06 '13 at 10:19
  • If a property is private it is not exposed. It is private. – JoeFryer Sep 06 '13 at 10:27
  • It still exposes accessor methods to subclasses. While they are not compile-time visible they still can be (accidentally) overridden. Imagine that Apple would use a private property named `status` in `UIViewController`'s implementation. Anybody who derives from UIViewController and add their own `status` accessor would unintentionally interfere with Apple's implementation. – Nikolai Ruhe Sep 06 '13 at 10:31