Where to put iVars in “modern” Objective-C?

by

The ability to put instance variables in the @implementation block, or in a class extension, is a feature of the “modern Objective-C runtime”, which is used by every version of iOS, and by 64-bit Mac OS X programs.

If you want to write 32-bit Mac OS X apps, you must put your instance variables in the @interface declaration. Chances are you don’t need to support a 32-bit version of your app, though. OS X has supported 64-bit apps since version 10.5 (Leopard), which was released over five years ago.

So, let’s assume you are only writing apps that will use the modern runtime. Where should you put your ivars?

Option 0: In the @interface (Don’t Do It)

First, let’s go over why we don’t want to put instance variables in an @interface declaration.

  1. Putting instance variables in an @interface exposes details of the implementation to users of the class. This may lead those users (even yourself when using your own classes!) to rely on implementation details that they should not. (This is independent of whether we declare the ivars @private.)

  2. Putting instance variables in an @interface makes compiling take longer, because any time we add, change, or remove an ivar declaration, we have to recompile every .m file that imports the interface.

So we don’t want to put instance variables in the @interface. Where should we put them?

Option 2: In the @implementation without braces (Don’t Do It)

Next, let’s discuss your option 2, “Put iVars under @implementantion without block of curly braces”. This does not declare instance variables! You are talking about this:

@implementation Person

int age;
NSString *name;

...

That code defines two global variables. It does not declare any instance variables.

It’s fine to define global variables in your .m file, even in your @implementation, if you need global variables – for example, because you want all of your instances to share some state, like a cache. But you can’t use this option to declare ivars, because it doesn’t declare ivars. (Also, global variables private to your implementation should usually be declared static to avoid polluting the global namespace and risking link-time errors.)

That leaves your options 1 and 3.

Option 1: In the @implementation with braces (Do It)

Usually we want to use option 1: put them in your main @implementation block, in braces, like this:

@implementation Person {
    int age;
    NSString *name;
}

We put them here because it keeps their existence private, preventing the problems I described earlier, and because there’s usually no reason to put them in a class extension.

So when do we want to use your option 3, putting them in a class extension?

Option 3: In a class extension (Do It Only When Necessary)

There’s almost never a reason to put them in a class extension in the same file as the class’s @implementation. We might as well just put them in the @implementation in that case.

But occasionally we might write a class that’s big enough that we want to divide up its source code into multiple files. We can do that using categories. For example, if we were implementing UICollectionView (a rather big class), we might decide that we want to put the code that manages the queues of reusable views (cells and supplementary views) in a separate source file. We could do that by separating out those messages into a category:

// UICollectionView.h

@interface UICollectionView : UIScrollView

- (id)initWithFrame:(CGRect)frame collectionViewLayout:(UICollectionViewLayout *)layout;
@property (nonatomic, retain) UICollectionView *collectionViewLayout;
// etc.

@end

@interface UICollectionView (ReusableViews)

- (void)registerClass:(Class)cellClass forCellWithReuseIdentifier:(NSString *)identifier;
- (void)registerNib:(UINib *)nib forCellWithReuseIdentifier:(NSString *)identifier;

- (void)registerClass:(Class)viewClass forSupplementaryViewOfKind:(NSString *)elementKind withReuseIdentifier:(NSString *)identifier;
- (void)registerNib:(UINib *)nib forSupplementaryViewOfKind:(NSString *)kind withReuseIdentifier:(NSString *)identifier;

- (id)dequeueReusableCellWithReuseIdentifier:(NSString *)identifier forIndexPath:(NSIndexPath*)indexPath;
- (id)dequeueReusableSupplementaryViewOfKind:(NSString*)elementKind withReuseIdentifier:(NSString *)identifier forIndexPath:(NSIndexPath*)indexPath;

@end

OK, now we can implement the main UICollectionView methods in UICollectionView.m and we can implement the methods that manage reusable views in UICollectionView+ReusableViews.m, which makes our source code a little more manageable.

But our reusable view management code needs some instance variables. Those variables have to be exposed to the main class @implementation in UICollectionView.m, so the compiler will emit them in the .o file. And we also need to expose those instance variables to the code in UICollectionView+ReusableViews.m, so those methods can use the ivars.

This is where we need a class extension. We can put the reusable-view-management ivars in a class extension in a private header file:

// UICollectionView_ReusableViewsSupport.h

@interface UICollectionView () {
    NSMutableDictionary *registeredCellSources;
    NSMutableDictionary *spareCellsByIdentifier;

    NSMutableDictionary *registeredSupplementaryViewSources;
    NSMutableDictionary *spareSupplementaryViewsByIdentifier;
}

- (void)initReusableViewSupport;

@end

We won’t ship this header file to users of our library. We’ll just import it in UICollectionView.m and in UICollectionView+ReusableViews.m, so that everything that needs to see these ivars can see them. We’ve also thrown in a method that we want the main init method to call to initialize the reusable-view-management code. We’ll call that method from -[UICollectionView initWithFrame:collectionViewLayout:] in UICollectionView.m, and we’ll implement it in UICollectionView+ReusableViews.m.

Leave a Comment