Objective-C: Private variables VS private properties

Question

For me the past as Objective-C developer was simple. Every field a class needed to be public was a property and every private field was an instance variable without getter or setter. But much more often I see people using a private interface inside the implementation file to declare private properties. And I have been told that is the way to do things now.

While this works fine it is hard for me to see the advantages. As long I do not need some logic in the getter or setter I would go on still using instance variables for everything not public. I have to admit using a property and then using keyword self make the code a bit more readable. You can see if a property belongs to the class or if it is just a local variable inside a method but that can not be the only reason.

Why or why not use private properties?

Answer 1

There are a couple of reasons to use (private) properties over ivars.

• As you said, using properties will allow you to easily use accessor methods that do some additional coding besides just accessing the variable.
• KVO does not work with ivars.
• Making a public readonly property readwrite only for the implementation, to have a setter synthesized in addition to the getter (as pointed out by Brad)
• Personal preference, habituation or laziness (property was public, but was changed to private).

Answer 2

First, if you do not need a private property, do not use a property: unless you want to get some specific behavior from the compiler declaratively, such as forcing NSString copying on assignment, there is no benefit to using properties.

Moreover, you do not necessarily need to use self to access these properties: when a property is synthesized for you, automatically or with a @synthesize keyword, you get a variable that "backs" the property. Assigning that variable is a perfectly legal way of accessing the property, for example, when you want to present it as read-only.

However, it an advantage to making these variables private, i.e. to declaring them in a class extension, like this:

@interface MyClass() { // <<== Note the () -- it's a class extension
   SomeOtherClass *privateIvar;
}

If you declare a variable in a class extension (which goes in .m file instead of a header) you would be able to hide the header for "SomeOtherClass", which is of little importance when you develop a single app, but becomes very useful when you start developing with your own class libraries.

Answer 3

IMO the OP is asking why put some ivars in the interface and some in the implementation. A side issue is why properties.

1. The point is encapsulation. Put only those things in the public interface (.h) file that are meant to be used by design outside the class. Put those that are by design to be used only in the implementation inside the implementation (.m) file. That was anything that is not publicly exposed can be changed later without affecting the users of the class.

2. Properties provide setter/getter methods for the associated ivars. In the current objective-c compiler if there is no @synthesize statement the compiler will auto generate the ivar with the same name as the property prefixed with an underscore (_). The getter/setters also support KVO, that may be a plus depending on your usage. Note that is it possible to declare a property readonly in the interface file and readwrite in the implementation file class extension.

So, the current best practice is to use properties for all ivars and put the property statements either in the interface file if they are designed to be public or in the implementation file in a class extension if they are designed to be private. This provided a clean interface file that only exposes public methods and properties.

Answer 4

properties in objective-c are not simply instance variables. they are a combination of getter and setter methods backed by an instance variable.

usually when people add properties in the implementation file (private class extension) it is to make a publicly readonly property a readwrite property so they can set it and retain all the property semantics like key-value coding. properties also take care of copy-retain for you.

Its just a method of keeping your public interface separate from the implementation.

Answer 5

It is just a matter of encapsulation you can have many different levels of privateness...

Originally in Objective-C the runtime didn't support adding actual fields at runtime to the Object, so every iVar had to be listed in the class:

@interface MyClass : NSObject
{
//every ivar that MyClass adds to NSObject must be here
}

This was a simple and good enough system for a while...

even private iVars had to be declared, although the compiler wouldn't let you access them in the wrong scope.

@interface MyClass : NSObject
{
 @private
 id someObj;
}

this visibility specifier limited access like:

//someotherclass.m

 + (void)doSomething
 {
     MyCLass * mc = [MyClass new];
     mc->someObj = [SomeOtherClass new]; // error cant access private variable...
 }

but you could potentially get to it with pointer arithmatic, so to obfuscate you will see things like this in classes:

@interface MyClass : NSObject
{
 @private
 void * __reserved1;
 void * __private1;
}

that is pretty good obfuscation...

But Wait.... THERE HAS TO BE A BETTER WAY!

enter the non fragile ABI

now classes only need to export their super class and public interfaces.

@interface MyClass : NSObject
@property (readonly,retain) id someIVar;

and the rest of the classes contents can be included in the class extension:

@interface MyClass ()
{
 id someObj;
}
@property (readwrite,retain) id someIVar;

beware that this will only work for iPhone and 64bit OS X 32-bit OS X is still the old ABI and libraries that need to work there will need to be the old way.

Answer 6

Well using properties might be more "convenient" (at least because you do not have to worry about forgetting calling willChange / didChange in case of KVO-able properties) and, no doubt, it's faster to use ivars instead of properties. So I would suggest using properties unless you are really concerned about frames per second. Check out this awesome post if that's the case.

Answer 7

It's really simple.

If you want to use a private @property, add this property inside your .m :

@interface MyViewController ()

@property (nonatomic, strong) NSString *myPrivateStringProperty;

@end

@implementation MyViewController

@end

Here, the property is only accessible in your .m.

If you want to use a public @property, add this property inside your .h :

@interface MyViewController : UIViewController

@property (nonatomic, strong) NSString *myPublicStringProperty;

@end

Here, the property is accessible outside your class.