CODEWITHSUNDEEP
ios
user1213042
user1213042

Reputation:

Declaring variables in .h file

Just wondering if its good programing practice to have a lot of variables declared in the .h file.

I'm writing my first app through which im learning xcode and obj-c. This ios app has just one xib, one .m and one .h file. I find my self a lot of times where i have a certain variable that i need to use in different methods/places in the .m file and i just end up declaring it in the .h file which seems like im making the variable global which i dont think is a good idea to have a lot of those.

Is this safe/ok to have a lot of variables declared in .h file or should i approach it in some other way?

Thanks

Upvotes: 2

Views: 1837

Answers (3)

Stunner
Stunner

Reputation: 12194

It is alright for you to have many variables declared in the interface in the .h file when needed (as touched on by the other answers). But it would be wise for you to consider moving instance variables that do not need to be public into a category in the .m file. For example:

In the .h:

#import <Foundation/Foundation.h>

@interface SomeClass : NSObject {
  NSDictionary *publicDict;
  NSArray *privateArray;
}

@property (nonatomic, strong) NSDictionary *publicDict;

-(void)publicMethod:(id)anObj;

@end

And in the .m file:

#import "SomeClass.h"

@interface SomeClass () //Category that denotes private methods

@property (nonatomic, strong) NSArray *privateArray;

-(void)privateMethod;

@end

@implementation

@synthesize publicDict;
@synthesize privateArray;

-(id)init {
  //...
}

-(void)publicMethod:(id)anObj {
  //..
}

-(void)privateMethod {
  //..
}

@end

This causes the compiler to issue a warning whenever any of the private methods contained in that category are accessed by outside classes. Additionally, this is the widely accepted way of adhering to an aspect of encapsulation in Objective-C.

Upvotes: 0

jrturton
jrturton

Reputation: 119242

Your .h file is the public interface of your class. It should only contain properties and methods that other classes need to know about.

You can declare ivars and internal methods and properties in a class continuation in the .m file (this is so common that one is now automatically included in the template for UIViewController subclasses).

You can also declare ivars within braces directly after the @implementation.

In iOS5, with ARC, declared ivars are strong references by default, so you don't have to use properties or accessor methods, but that choice depends on the rest of your class. For example, you may use lazy instantiation or perform other tasks or KVO when getting or setting a variable, in which case you'd always want to access it via a property or method, and if you're doing that for some ivars, and not others, it starts to look a bit messy.

Upvotes: 1

CodaFi
CodaFi

Reputation: 43330

Is this safe/ok to have a lot of variables declared in .h file or should i approach it in some other way?

It's absolutely OK to include a lot of variables in the .h! It just increases compile time a little and increases the size of your binary by an arbitrary amount. If it worries you, just split your implementation across a couple of categories.

I find my self a lot of times where i have a certain variable that i need to use in different methods/places in the .m file and i just end up declaring it in the .h file which seems like im making the variable global which i dont think is a good idea to have a lot of those.

Variables that are accessed outside of one method should always be declared as iVars, and as properties if they require strong reference, or need to be accessed by outside classes. Global variables are way different, and you needn't worry about it.

Upvotes: 2

Related Questions