1

In my ViewController I have created some objects that I need to use throughout various places in the controller itself, but nowhere outside of it. I have done it like this:

@implementation MyController1

NSString *myString;

- (void)myFirstMethod {
   myString = @"hello world";
}
...
@end

I haven't put them in the header file nor have I defined them with @property in an interface declaration that would look like this:

@interface MyController1 ()
    // could define myString with @property here
@end

I'm not having any problems with my code, but I wanted to make sure that I'm not violating safe practices. I know I could put them in the header or implementation file and use @private, but for the sake of code brevity I haven't. Is this okay to do? Does no longer having to use @synthesizehave any impact on this?

Thanks,

Swifty McSwifterton
  • 2,637
  • 1
  • 30
  • 37
  • Its basically your choice; take a look at; http://stackoverflow.com/questions/11478038/reason-to-use-ivars-vs-properties-in-objective-c Yes, you lose out on some things using an instance variable but if you don't need KVC and stuff, its fine. – cream-corn Feb 28 '14 at 02:28
  • Sorry to spam: but it is convention to have instance variables prefixed with '_' so '_myString' And as an alternative, you can have a private category on MyController1 and declare a "private" property – cream-corn Feb 28 '14 at 02:33
  • Pump the brakes on the _ prefixed instance variables... When you declare a property, setters and getters are auto-synthesized for you, as `propertyName = _propertyName`. While the compiler will let you declare instance variables that begin with an underscore, you're just begging for confusion and impossibly tedious to debug problems. – ryan cumley Feb 28 '14 at 03:50

1 Answers1

1

It's perfectly fine, just as long as you are aware of the difference between an instance variable (a.k.a. "member variable" or "ivar") and a static variable. For example, there will only be one string object associated with your myString variable in your example here (@"hello world"), no matter how many MyController1 objects you create, not one per instance of the class MyController1. So in this way, myString is not behaving like a property nor an instance variable.

Furthermore, the static variable's life cycle is longer -- it will outlive all instances of your MyController1 objects, only being deallocated when the program exits or if you explicitly do so, say if you allocated it on the heap to begin with (which you are not doing in the case of @"hello world", but of course could potentially do with other static variables).

There are pros and cons to both types/approaches. For example, ivars can keep track of object state, but this means each instance of your objects are bigger because they must each have memory allocated for that state. So if memory performance matters in your app, ivars shouldn't be used unless you need them. On the other hand, static variables are good for "one offs" -- things that are not associated with the object state, but often have to be protected if they can be written to by more than one object on more than one thread. These are just some contrasts... there are many others depending on what you're trying to do.

Re your final question about @synthesize, not using it just means that there won't be any auto-generated accessors for the variable, which is fine because the variable isn't an ivar and not associated with instances of the MyController1 object anyway.

Turix
  • 4,470
  • 2
  • 19
  • 27
  • Between this answer and this post: http://stackoverflow.com/questions/6143107/compiler-error-initializer-element-is-not-a-compile-time-constant I now understand the true nature of what I'm doing. Thanks. – Swifty McSwifterton Feb 28 '14 at 05:21