4

Will usage of static variables expose them to a danger of being modifiable from anywhere ?(In context of Objective-C). If yes, can someone suggest best alternatives for using shared variables across all classes ?

Bryan Chen
  • 45,816
  • 18
  • 112
  • 143
Ankit Malhotra
  • 194
  • 6

2 Answers2

4

Is using too many static variables in Objective-C a bad practice?

Yes. Of course, "too many" has not been quantified and is subjective. Really, global/static variables are very rarely a good thing -- very convenient to introduce and very difficult to debug and eliminate. Also rare is the case that they are good design. I've found life far easier without them.

Will usage of static variables expose them to a danger of being modifiable from anywhere? (In context of Objective-C).

It depends on where they are declared and how they are used. If you were to pass a reference to another part of the program, then they would be modifiable from 'anywhere'.

Examples:

If you place them so that only one file can "see" the variable (e.g. in a .m file following all includes), then only the succeeding implementation may use it (unless you pass a reference to the outside world).

If you declare the variable inside a function, then it is shared among each translation and copied for each translation in C/ObjC (but the rules are very different in C++/ObjC++).

If yes, can someone suggest best alternatives for using shared variables across all classes?

Just avoid using globals altogether. Create one or more type/object to hold this data, then pass an instance of it to your implementations.

Singletons are the middle ground, in that you have some type of global variable/object based abstraction. Singletons are still so much hassle -- they are categorized as global variables and banned in my codebase.

justin
  • 104,054
  • 14
  • 179
  • 226
  • Thanks for your views justin. So yeah, I do pass the reference of some of my static variables to other classes, which probably means that these variables will be exposed for sure. Can you possibly provide me an example telling about creating one or more type/object to hold this data ? As an example scenario, I have a static variable: `static NSString *userID;` and I pass this to the function: `-(void)passUserID: (NSString *)id;` – Ankit Malhotra May 19 '13 at 08:27
  • 1
    @AnkitMalhotra you would literally make an objc class which has a property/ivar `NSString * userID;` and delete the static variable. then you pass an instance of the class you made to whichever implementations need the user ID (e.g. as a parameter or hold a reference), rather than referring to the static. – justin May 20 '13 at 04:43
  • thanks @justin So using `@property(nonatomic,copy)NSString *userID;` should do fine ? or should it be `(nonatomic,read)` ? – Ankit Malhotra May 21 '13 at 03:56
  • @AnkitMalhotra a) yes. at least, that would be the first step in eliminating the global variable. you then pass the object which declares that property to your implementations that need the `userID`. b) in general: favor `readonly` where you can get away with it. this doesn't mean to instead change the value behind your implementations' back, but if you can set the value in the initializer and it never needs to change, then do not bother introducing complexity associated with changes to the property value. similarly, that property may only need to use a setter from the private imp (cont) – justin May 21 '13 at 04:10
  • (cont) in which case, you could declare the setter in the class continuation and make only the getter public if the getter is all that is needed in the public interface. – justin May 21 '13 at 04:11
  • thanks @justin. This way it works good. Meanwhile, I also thought that declaring my static variable within my .m file should limit its scope only to that implementation class. That way they should not get exposed to other classes with a danger of being modified. – Ankit Malhotra May 21 '13 at 23:47
  • @AnkitMalhotra yes, declaring them in the `*.m ` is a big improvement over header declarations. – justin May 22 '13 at 05:27
3

Static variables are local to the translation unit, so the variables are definitely not modifiable from anywhere. Globals, which are closely related to statics in that they are allocated in the same memory area, are modifiable from anywhere, and that's their main danger.

When you need a group of variables to be accessible from anywhere in your project, the common approach is implementing a singleton that holds related data, and contains methods for processing that data. In MVC apps implemented in Objective C the model is often accessed through a singleton model object.

My scenario involves a number of static variables declared in the .h file & they are assigned values in specific methods declared in those .h files.

If you declare statics in the header, they become "disconnected" from each other: each translation unit (i.e. each .m file) gets its own set of statics from the header. This is usually not what you want.

If you make these variables global, you end up with a plain C, not an Objective C, solution. You should put these variables in a class as properties, and move function implementations with them into the methods of your class. Then make the class a singleton as described in the answer linked above to get a solution that is easier to understand than the corresponding solution based on globals.

Community
  • 1
  • 1
Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • Thanks for your views dasbkinkenlight. My scenario involves a number of static variables declared in the .h file & they are assigned values in specific methods declared in those .h files. I don't think this follows the singleton approach exactly as you described above, is it anyway a considerable approach ? thanks.. – Ankit Malhotra May 19 '13 at 08:11
  • @AnkitMalhotra one danger in the approach you have outlined is that you can end up with copies of those static variables (e.g. one per translation where the header is included). even when it could it debatably useful, there is a better way. – justin May 21 '13 at 04:16
  • thanks @justin. I think, in this case, if i declare all my static variables within the .m file, it should be fine. This should avoid multiple copies of static variables wherever i import my .h files, as the variables wont exist in .h files. – Ankit Malhotra May 21 '13 at 23:55