Objective-C: cases when it is useful to override +initialize and +load

Question

The title is the question's formulation - i.e. what are the patterns and anti-patterns of +initialize and +load class methods overriding?

Have you met particular examples? If yes - please describe.

P.S. There was some good Q&A on +load and +initialize here on StackOverflow but no one tells about the practical interest of these methods. Mechanisms were discussed.

Answer 1

+load is useful for setting up stuff needed for categories because all the +load methods are guaranteed to be called once each when the binary is loaded (even if there are multiple +load methods for the same class, which normally would replace one another). Inheritance is actually irrelevant to its functioning.

Answer 2

I almost never use +load, but +initialize is useful for all sorts of things... setting up static variables, dynamically loading libraries for plugin architectures... anything you want to do one time like printing version info, setting up a global instance to do something specialized, like for logging, crash reporter, signal handler, etc...

edit:

to prevent multiple initialize calls from messing stuff up (which happens to superclasses when the child class is used after a superclass): you can make it reentrant (this is a common pattern):

+(void) initialize {
    static BOOL inited = NO;
    if(!inited)
    {
       /*dostuff*/
       inited=YES;
    }
}

Answer 3

A good use of the load method is to initialize global variables that can't be initialized at compile-time.

Here is a made up example:

SomeClass.h

extern NSString *SomeGlobalConstant;

// Followed by some class interface stuff

SomeClass.m

#import "SomeClass.h"

NSString *SomeGlobalConstant = nil;

static NSArray *someFileStaticArray = nil;

@implementation SomeClass

+ (void)load {
    if (self == [SomeClass class]) {
        SomeGlobalConstant = @"SomeAppropriateValue";

        someFileStaticArray = @[ @"A", @"B", @"C" ];
    }
}

// and the rest of the class implementation

@end

Answer 4

Another possible use of +initialize is for Method Swizzling. Which you shouldn't really use unless you're sure you know what you're doing. Read this SO question for more details.

It allows you to substitute an existing method implementation with your own, and still be able to call the original one. For instance, for faking NSDate in unit tests you could write something like this (note, that there are other ways to do this (OCMock, etc.), this is just an example). This code allows you to set a program-wide fake NSDate, which will be returned whenever [NSDate date] is called. And if no fake date is set, then the original implementation is used.

#import "NSDate+UnitTest.h"
#import "MethodSwizzling.h"

@implementation NSDate(UnitTest)

static NSDate *fakeCurrentDate = nil;

+(void)setFakeCurrentDate:(NSDate *)date
{
    fakeCurrentDate = date;
}

+(NSDate *)fakeCurrentDate
{
    if (fakeCurrentDate) {
        return fakeCurrentDate;
    }
    else {
        NSDate *result = [self fakeCurrentDate];
        return result;
    }
}

+(void)initialize
{
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        NSLog(@"Swizzling...");
        SwizzleClassMethod([self class], @selector(date), @selector(fakeCurrentDate));
    });
}

@end

//MethodSwizzling.m:

void SwizzleMethod(Class c, SEL orig, SEL new, BOOL isClassMethod) {
    NSLog(@"Swizzling %@ method %@ of class %@ with fake selector %@.",
          (isClassMethod ? @"a class" : @"an instance"),
          NSStringFromSelector(orig),
          NSStringFromClass(c),
          NSStringFromSelector(new));

    Method origMethod = isClassMethod ? class_getClassMethod(c, orig) : class_getInstanceMethod(c, orig);
    Method newMethod = isClassMethod ? class_getClassMethod(c, new) : class_getInstanceMethod(c, new);

    method_exchangeImplementations(origMethod, newMethod);
    //Actually, it's better to do it using C-functions instead of Obj-C methods and
    //methos_setImplementation instead of method_exchangeImplementation, but since this
    //is not an open-source project and these components aren't going to be used by other people,
    //it's fine. The problem is that method_exchangeImplementations will mess things up if
    //the implementation relies on a fact that the selector passed as a _cmd parameter
    //matches the function name.
    //More about it: http://blog.newrelic.com/2014/04/16/right-way-to-swizzle/
}

void SwizzleClassMethod(Class c, SEL orig, SEL new) {
    SwizzleMethod(c, orig, new, YES);
}

void SwizzleInstanceMethod(Class c, SEL orig, SEL new) {
    SwizzleMethod(c, orig, new, NO);
}