How Apple Uses Static Class Methods, What's Cool and What's Not

Apple follows an interested pattern, I haven't figured out this pattern's name yet. Basically they put static utility methods that operate on a particular class in that class. This avoids breaking out separate controller or helper classes. Our own code can adopt this pattern as well. Consider many of the helper classes you have that are just have static utility methods. If they are operating on one of your own custom object types, you might consider putting that static method in the custom class instead. The benefit to doing this is that you have code that operates specifically on that class instance right there next to the instance code. Also, this eliminates extra files that are not needed and extra imports. If you are already using that object, then you've already imorted it as well and you'll thereby also get access to those static methods.

Let's make this point a little clearer with an example from Apple. Apple provides an API for animating UIView objects. Since UIView objects and UIView subclasses are primarily the only objects that can be animated anyway Apple put the static animate method in the UIView class instead of breaking out a separate UIViewAnimator class. Let's see this in action.

[UIView animateWithDuration:2 animations:^{
   myView.frame = CGRect(0,0,myView.frame.size.width,myView.frame.size.height);
}];

Notice that animation is a stateless operation. Stateless operations are a key indicator for a potential static method candidate. The only state being changed above is the state of the parameterized input, the views themselves. For this reason a static class method is a good fit. Keep reading, later on in this post I'm going to go into some of Apple's yucky state changing static methods.

A convenience, or secondary, initializer is an initializer that makes initialization easier because the convenience initializer will internally call the designated initializer with default values that don't need to be passed in as parameters. The designated initializer, or primary initializer, calls super init in its implementation and also handles all of the possible initial parameterized values.

Below is an example of how to correctly use designated initializer and factory convenience initializer. Now in Xcode 6 and iOS 8 you can use NS_DESIGNATED_INITIALIZER so the compiler can help give you warnings if you misuse the designated initializer ie: if a convenience initializer doesn't call designated initializer you will get a warning.

Person.h

+ (instancetype)newbornNamed:(NSString *)name;
- (instancetype)initWithName:(NSString *)name age:(NSUInteger)age children:(NSArray *)children NS_DESIGNATED_INITIALIZER;

Person.m

+ (instancetype)newbornNamed:(NSString *)name {
   return [[[self class] alloc] initWithName:name age:0 children:nil];
}
- (instancetype)initWithName:(NSString *)name age:(NSUInteger)age children:(NSArray *)children NS_DESIGNATED_INITIALIZER {
   if (self = [super init]) {
      self.age = age;
      self.children = children;
   }
   return self;
}

Calling Code

// Convenience
Person *baby = [Person newbornNamed:@"Amy"];

// Designated
Person *parent = [[Person alloc] initWithName:@"Bob" age:25 children:@[baby]];

Ok so let's compare the far-fetched example above to NSDate. It also has a static convenient initializer for a brand-new date just as we did for a brand-new person. [NSDate date]. Wow, that was simple. That returns an NSDate instance that represents the current date and time.

[[UINavigationBar appearance] setTintColor:[UIColor redColor]];