Objective-C's Designated Initializer Pattern

Out of the box in Objective-C you can initialize an instance of a class by
calling alloc and init on it.

// Creating an instance of Party

Party *party = [[Party alloc] init];

Alloc allocates memory for the instance, and init gives it’s instance
variables it’s initial values. Both return pointers to the new instance, hence
the method chain. In this case, unless init was re-implemented in the Party
class, any instance variables in the party instance were set to 0, or the zero
pointer otherwise known as nil.

That’s no good. I am of the opinion that we should always strive to create
complete objects, i.e. objects who never have nil values for their instance
variables. In Objective-C there’s even a better reason for doing this. in
Objective-C a message sent to nil is silently ignored. An unexpected nil value
could create a debugging nightmare for you.

So how do we do initialize the variables? Here’s one way.

// Setting Party values using accessors after initialization

Party *party = [[Party alloc] init];
party.date = [NSDate date];
party.location = @"Unicorn Office";
party.attendees = @[@"Joel",@"Bill",@"Peter"];

But that’s terrible. There’s danger in setting properties after the fact. The
user could fail to set the state of a vital instance variable, and as the
class designer, we’re not being good citizens. I can’t really put it any
better than Kent Beck does in “Smalltalk Best Practice Patterns”.

“what is the first thing you want to know about a class, once you’ve decided
it may do what you want it to do? The first question is “what does it take to
create an instance?” As a class provider, you’d like the answer to this
question to be as simple as possible. With the style described above, you have
to track down references to the class and read the code before you get an
inkling of how to create a useable instance. If the code is complex, it may
take a while before you figure out what is required and what is optional in
creating an instance.”

As class designers, we want to make sure there is method to represent each
valid way to create an instance. Beck describes the pattern as the “Complete
Creation Method”, Objective-C calls it “Designated Initializer”.

Maybe in the domain of our example, a party can be created and have a default
date if none is provided, and can have no attendees initially, but it really
must have a location or it just doesn’t make sense to create it.

// Calling a customer Party initializer

Party *party = [[Party alloc] initWithLocation: @"Unicorn Office"];

It could be there are times it makes sense to initialize the other values,
date and attendees. If we provided the protocol to do so the Party.h class
interface might look like this.

// The Party initializers interface

#import <Foundation/Foundation.h>

@interface Party : NSObject

@property (nonatomic,strong) NSDate* date;
@property (nonatomic,strong) NSString* location;
@property (nonatomic,strong) NSArray* attendees;


-(Party*)initWithLocation:(NSString*)location;
-(Party*)initWithLocation:(NSString*)location date:(NSDate*)date;
-(Party*)initWithLocation:(NSString*)location attendees: (NSArray*)attendees;
-(Party*)initWithLocation:(NSString*)location date:(NSDate*)date attendees:(NSArray*)attendees;

@end

There are the four valid ways you can create a party. The trick is that only
one of these methods really sets the instance variables at the end of the day.
That method is called the Designated Initializer, and all other initializers
defer to it, directly or indirectly. Take a look at the implementation.

// Implementation of Party initializers deferring to a Designated Initializer

#import "Party.h"

@implementation Party

-(Party*)initWithLocation:(NSString*)location {
    return [self initWithLocation: location date:[self defaultDate] attendees:[self defaultAttendees]];
};

-(Party*)initWithLocation:(NSString*)location date:(NSDate*)date{
    return [self initWithLocation: location date:date attendees:[self defaultAttendees]];
};

-(Party*)initWithLocation:(NSString*)location attendees: (NSArray*)attendees{
    return [self initWithLocation: location date:[self defaultDate] attendees: attendees];
};

-(Party*)initWithLocation:(NSString*)location date:(NSDate*)date attendees:(NSArray*)attendees{
    self = [super init];
    self.location = location;
    self.date = date;
    self.attendees = attendees;
    return self;
};

-(NSDate*)defaultDate {
    return [NSDate date];
}

-(NSArray*)defaultAttendees {
    return @[];
}

@end

In Party, initWithLocation:date:attendees: is the Designated Initializer. It
has parameters for the most important and frequently used instance variables
of Party. It is called from all of the other initializer methods. Those
methods make use of shared default settings where values are not passed in.

It is also possible that initializers could call initializers other than the
Designated Initializer to achieve the same effect. initWithLocation: could
defer to initWithLocation:date: which would defer to
initWithLocation:date:attendees:. Regardless of whether initWithLocation:
defers to initWithLocation:date:attendees: directly or indirectly, all rounds
lead to the Designated Initializer.

The Designated Initializer gives us a central point where modifications to
instance creation can happen, giving us the most control over how instances
are initialized. At the end of the deferment chain, there is only one method
that is responsible for setting the initial state of the object, and a
complete object comes out every time.