Difference Between Declaring a Variable Under @Implementation And @Interface Under .m file

Question

I have been learning Objective-C for awhile. From what I learned, I know that when you declare a variable inside @interface in the .h file, the variable can be accessed publicly(similar as a public variable in java).

@interface MyObject

@property NSInteger intData;

@end

But when you declare it inside @interface in the .m file. It can only be accessed inside the .m file under @implementation only, unless you provide a getter and setter for it.

@interface MyObject ()

@property NSInteger intData;

@end

But I also noticed another way of declaring a variable, which is declaring it under @implementation

@implementation

NSInteger intData;

@end

and I see that it works the same way as declaring it under @interface with @property in .m file

I don't understand the difference between the two(declaring under @implementation and under @interface(in .m file).

I've already searched through stack about this, but they were all talking about the difference between @implementation and @interface(in .h file). So think this is not a duplicate.

Answer 1

First off, you're not declaring a variable; you're declaring a property. A property is backed by an instance-variable, but it also adds methods. Here's an explanation of the places to put variables:

@interface MyClass : NSObject {
    NSInteger i ;
}
@end

This is a place to put an instance variable on your class. It is only accessible by methods of your class and categories. (Sidenote: it CAN be made accessible externally, but that's not a recommended practice)

Another example:

@interface MyClass : NSObject
@end

@implementation MyClass {
    NSInteger i ;
}
@end

This is also an instance variable, but is only accessibly by methods written inside that block. (Sidenote: it can be accessed by digging through the class definition, but that's not a recommended (or common) practice)

Another example:

@interface MyClass : NSObject
@property NSInteger i ;
@end

Is the same as:

@interface MyClass : NSObject {
    NSInteger _i ; // you are not allowed to access it by this variable
}
- (NSInteger) i ;
- (void) setI:(NSInteger)value ;
@end

This is a property people are allowed to get and set. You use that variable in your methods or in other methods as:

NSLog ( @"The value is %i" , self.i ) ; // if it's your instance method
NSLog ( @"The value is %i" , object.i ) ; // if it's object's instance method

Another example:

@interface MyClass : NSObject {
    NSInteger i ;
}
@property NSInteger i ;
@end
@implementation MyClass
@synthesize i ; // Causes the property to line up with the ivar by the same name.
@end

Is the same as:

@interface MyClass : NSObject {
    NSInteger i ; // you ARE allowed to use this since you defined it
}
- (NSInteger) i ;
- (void) setI:(NSInteger)value ;
@end

Here, you can use the getter/setter methods or the instance variable itself. However, you should generally use the methods because you [implicitly] declared them atomic so they have threading synchronization. If you want to make it NOT do threading (and speed it up, as long as you're not going to use it in a multi-threaded environment):

@property (nonatomic) NSInteger i ;
@property (nonatomic,readonly) NSInteger i ; // only makes a getter method

I'd recommend avoiding this for a while and use the straight properties because it'll help you avoid a lot of common mistakes. Unless you profile your program and determine that this is a cause of a performance loss, you should probably simply use the properties.

Another example:

@interface MyClass : NSObject
@end

@implementation MyClass
NSInteger i ;
@end

This is NOT an instance variable. It is a global variable that happens to have been written inside your @implementation scope.

See above for how to turn this into an instance variable (i.e. putting it in braces).

One more note:

Declaring a property like this:

@interface MyClass ()
@property NSInteger i ;
@end

Doesn't make it private. However, it is hidden in a file that people generally can't access so the compiler doesn't know a property exists.

Other functions elsewhere in your code CAN still call:

[yourObject i] ;

To get the value of that property - but they have to know it's there first.

Addendum to answer a question in the comments:

Properties are, by default, atomic. It doesn't necessarily follow the strict definition of atomic (this is a can of worms I suggest you not look at right now), but has the same effect: threads are guaranteed to see a complete and up-to-date value, regardless of when another thread writes to it. It generally does this when it synthesizes the getter/setter methods:

- (NSInteger) i {
    @synchronized(self) {
        return i ;
    }
}
- (void) setI:(NSInteger)value {
    @synchronized(self) {
        i = value ;
    }
}

If you instead specify nonatomic, it'll synthesize these:

- (NSInteger) i {
    return i ;
}
- (void) setI:(NSInteger)value {
    i = value ;
}

If your property is atomic, then you shouldn't ever access the ivar directly. Doing so violates the threading protection you gave it to begin with. (Sidenote: there are cases where you can, but wait until you become more familiar with threading/synchronization before you attempt it.)