iOS: Let's talk about Designated Initializer

1. iOS object creation and initialization

Object creation in iOS is done in two steps:

Allocate memory to initialize the member variables of the object

The process of creating NSObject objects that we are most familiar with is:

Apple has an official picture that describes this process more vividly:

Object initialization is a very important process. Usually, during initialization, we will support the initial state of member variables, create associated objects, etc. For example, for the following objects:

 @interface ViewController: UIViewController 
 
 @end 
 
 
 @interface ViewController () {
 XXService *_service;
 } 
 
 @end 
 
 @implementation ViewController 
 
 - (instancetype)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
 { 
     self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
 if (self) { 
         _service = [[XXService alloc] init];
 } 
      
 return self;
 } 
 
 - (void)viewWillAppear:(BOOL)animated
 {
    [super viewWillAppear:animated]; 
      
 [_service doRequest];
 } 
 
 ... 
 
 @end 
 
 Test ViewController

There is a member variable XXService in the VC above, which initiates a network request to obtain data to fill the VC when viewWillAppear.

Do you think there is any problem with the above code?

Let's continue reading with this question. There is only the VC implementation code above. We don't know how VC is created. There are two situations below:
1. Manual creation

Usually, in order to save trouble, we often use the following method when creating VC

 ViewController * vc = [ViewController alloc] init];
 ViewController * vc = [ViewController alloc] initWithNibName:nil bundle:nil];

Using the above two methods to create, our above code can run normally because the member variable _service is initialized correctly.
2. Loaded or deserialized from storyboard

Let’s first look at an official Apple copy:

Since Xcode5, new projects created by default are managed and loaded in Storyboard mode. Object initialization does not call the initWithNibName:bundle: method at all, but calls the initWithCoder: method. Comparing with the above VC implementation, it can be seen that the _service object is not initialized correctly, so the request cannot be issued.

At this point, everyone should have the answer to the first question in their mind. Now let’s take a look at the deeper reasons behind the question.

The correct operation result does not mean the correct execution logic, sometimes it may just be a coincidence
2. Designated Initializer

In the header file of UIViewController we can see the following two initialization methods:

 - (instancetype)initWithNibName:(nullable NSString *)nibNameOrNil bundle:(nullable NSBundle *)nibBundleOrNil NS_DESIGNATED_INITIALIZER;
 - (nullable instancetype)initWithCoder:(NSCoder *)aDecoder NS_DESIGNATED_INITIALIZER;

Careful students may have discovered a macro "NS_DESIGNATED_INITIALIZER", which is defined in the header file NSObjCRuntime.h and is defined as follows:

 #ifndef NS_DESIGNATED_INITIALIZER
 #if __has_attribute(objc_designated_initializer)
 #define NS_DESIGNATED_INITIALIZER __attribute__((objc_designated_initializer))
 #else
 #define NS_DESIGNATED_INITIALIZER
 #endif
 #endif

"__has_attribute" is a macro of Clang used to detect whether the current compiler supports a certain feature. Yes, you heard it right, "__has_attribute" is also a macro.

From the above definition, we can see that "NS_DESIGNATED_INITIALIZER" actually adds a compiler-visible marker to the end of the initialization function declaration. Don't underestimate this marker, it can help us find some potential problems at compile time and avoid some strange behaviors when the program is running.

It sounds magical, how can the compiler help us avoid it?

The answer is: ⚠️⚠️⚠️ Warning

As shown below:

The compiler has a warning, which means that the code we wrote is not standardized. Xcode's built-in Analytics tool can help us find potential problems in the program. Spend more time standardizing your own code, eliminate warnings in the project, and avoid strange problems after the project goes online.
3. What is the correct way to use NS_DESIGNATED_INITIALIZER?

Designated Initializers vs. Convenience Initializers

The designated initialization function is very important for a class, and usually has the most parameters. Imagine that every time we need to create a custom class, we need a bunch of parameters, which is very painful. Convenience initialization functions are used to help us solve this problem, allowing us to create objects more easily while ensuring that the member variables of the class are set to default values.

However, please note that in order to enjoy these "conveniences", we need to comply with some specifications. The official document links are as follows:

Objective-C: https://developer.apple.com/library/mac/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html#//apple_ref/doc/uid/TP40014150-CH1-SW8

https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/MultipleInitializers.html

Swift: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Initialization.html

Swift and Objective-C are slightly different. Below we take the Objective-C specification as an example.

1. If a subclass has a designated initialization function, then the designated initialization function must call the designated initialization function of its direct superclass when implementing the designated initialization function.

2. If the subclass has a designated initialization function, then the convenience initialization function must call its own other initialization functions (including the designated initialization function and other convenience initialization functions) and cannot call the super initialization function.

Based on the definition in Article 2, we can infer that all convenient initialization functions will eventually be called to the designated initialization function of the class.

Reason: All convenient initialization functions must call other initialization functions. If the program can run normally, there will be no direct recursion or indirect recursion. Suppose a class has a specified function A and convenient initialization functions B, C, and D. No matter how B, C, and D are called, there will always be one person who breaks the cycle. Then there must be a call pointing to A, and the other two will eventually point to A.

The schematic diagram is as follows (the picture is ugly, just make sure you understand the meaning):

3. If a subclass provides a designated initialization function, then it must implement the designated initialization functions of all parent classes.

When a subclass defines its own designated initialization function, the designated initialization function of the parent class "degenerates" into a convenient initialization function of the subclass. The purpose of this specification is to "ensure that variables added by the subclass can be initialized correctly."

Because we cannot restrict users from creating subclasses in any way, for example, we can use the following three methods when creating UIViewController:

 UIViewController * vc = [[UIViewController alloc] init];
 UIViewController * vc = [[UIViewController alloc] initWithNibName:nil bundle:nil];
 UIViewController * vc = [[UIViewController alloc] initWithCoder:xxx];

4. Take an example

The above three specifications may be a bit confusing to understand. I wrote a simple example to help you understand the specification. The code is as follows:

 @interface Animal : NSObject {
 NSString *_name;
 } 
 
 - (instancetype)initWithName:(NSString *)name NS_DESIGNATED_INITIALIZER; 
 
 @end 
 
 @implementation Animal 
 
 - (instancetype)initWithName:(NSString *)name
 { 
     self = [super init];
 if (self) { 
         _name = name;
 } 
 
 return self;
 } 
 
 - (instancetype)init
 {
    return [self initWithName:@"Animal"];
 } 
 
 @end 
 
 
 @interface Mammal : Animal {
    NSInteger _numberOfLegs;
 } 
 
 - (instancetype)initWithName:(NSString *)name andLegs:(NSInteger)numberOfLegs NS_DESIGNATED_INITIALIZER; 
 
 - (instancetype)initWithLegs:(NSInteger)numberOfLegs; 
 
 @end 
 
 @implementation Mammal 
 
 - (instancetype)initWithLegs:(NSInteger)numberOfLegs
 { 
     self = [self initWithName:@"Mammal"];
 if (self) { 
         _numberOfLegs = numberOfLegs;
 } 
 
 return self;
 } 
 
 - (instancetype)initWithName:(NSString *)name andLegs:(NSInteger)numberOfLegs
 { 
     self = [super initWithName:name];
 if (self) { 
         _numberOfLegs = numberOfLegs;
 } 
 
 return self;
 } 
 
 - (instancetype)initWithName:(NSString *)name
 {
    return [self initWithName:name andLegs:4];
 } 
 
 @end 
 
 
 @interface Whale : Mammal {
 BOOL _canSwim;
 } 
 
 - (instancetype)initWhale NS_DESIGNATED_INITIALIZER; 
 
 @end 
 
 @implementation Whale 
 
 - (instancetype)initWhale
 { 
     self = [super initWithName:@"Whale" andLegs:0];
 if (self) { 
         _canSwim = YES ;
 } 
 
 return self;
 } 
 
 - (instancetype)initWithName:(NSString *)name andLegs:(NSInteger)numberOfLegs
 {
 return [self initWhale];
 } 
 
 - (NSString *)description
 {
    return [NSString stringWithFormat:@"Name: %@, Numberof Legs %zd, CanSwim %@", _name, _numberOfLegs, _canSwim ? @"YES" : @"NO"];
 } 
 
 @end 
 
 TestDesignatedInitializer

To match the above code, I also drew a class call diagram to help you understand it, as follows:

We declared three classes: Animal, Mammal, and Whale, and implemented all initialization functions according to the specification of designated initialization functions.

Next, we create some whales to test their robustness. The code is as follows:

 Whale * whale1 = [[Whale alloc] initWhale]; // 1
 NSLog(@"whale1 %@", whale1); 
 
 Whale * whale2 = [[Whale alloc] initWithName:@"Whale"]; // 2
 NSLog(@"whale2 %@", whale2); 
 
 Whale * whale3 = [[Whale alloc] init]; // 3
 NSLog(@"whale3 %@", whale3); 
 
 Whale * whale4 = [[Whale alloc] initWithLegs:4]; // 4
 NSLog(@"whale4 %@", whale4); 
 
 Whale * whale5 = [[Whale alloc] initWithName:@"Whale" andLegs:8]; // 5
 NSLog(@"whale5 %@", whale5);

The execution results are:

 whale1 Name: Whale, Number of Legs 0, CanSwim YES
 whale2 Name: Whale, Number of Legs 0, CanSwim YES
 whale3 Name: Whale, Number of Legs 0, CanSwim YES
 whale4 Name: Whale, Number of Legs 4, CanSwim YES
 whale5 Name: Whale, Number of Legs 0, CanSwim YES

The analysis shows that:

whale1 is created using Whale's designated initialization function. The initialization call order is: ⑧ -> ⑤ -> ③ -> ①. The actual execution order of the initialization method is exactly the opposite: ① -> ③ -> ⑤ -> ⑧, that is, initialization starts from the root class. The initialization order is exactly the same as the layout order of the class member variables. If you are interested, you can check it online.

whale5 uses the designated initialization function of Whale's parent class Mammal to create an instance. The initialization call order is: ⑦ -> ⑧ -> ⑤ -> ③ -> ①, and the created object meets expectations.

Note: ⑦ represents the implementation of the Whale class, whose internal implementation calls the designated initialization function initWhale of its own class. ⑤ represents the implementation of the Mammal class.

Careful friends may have noticed the fourth whale we created, which magically grew four legs. Let's look at the calling order of the creation process: ⑥ -> ④ -> ⑦ -> ⑧ -> ⑤ -> ③ -> ①. You can see that the initialization of the objects is also completely initialized in the order from the beginning to the current class. So where is the problem?

The initWithLegs: function of the Mammal class, in addition to the normal initialization function call stack, also has a function body that resets the value of the member variable _numberOfLegs of the initialized object, which causes the whale to grow four legs.

 - (instancetype)initWithLegs:(NSInteger)numberOfLegs
 { 
     self = [self initWithName:@"Mammal"];
 if (self) { 
         _numberOfLegs = numberOfLegs;
 } 
 
 return self;
 }

Careful students will find that no matter you use the initialization function of the parent class or the grandparent class to create an object of the subclass, the order of the last four calls is: ⑧ -> ⑤ -> ③ -> ①.

The specified initialization function rule can only be used to ensure that the object creation process initializes all member variables in sequence from the root class to the subclass, and cannot solve business problems.
5. When initWithCoder: encounters NS_DESIGNATED_INITIALIZER

The NSCoding protocol is defined as follows:

 @protocol NSCoding 
 
 - (void)encodeWithCoder:(NSCoder *)aCoder;
 - (nullable instancetype)initWithCoder:(NSCoder *)aDecoder; // NS_DESIGNATED_INITIALIZER 
 
 @end

Apple's official document Decoding an Object clearly states:

Translate:

If the parent class does not implement the NSCoding protocol, the designated initialization function of the parent class should be called.
If the parent class implements the NSCoing protocol, then the subclass's initWithCoder: implementation needs to call the parent class's initWithCoder: method.

According to the three rules of designated initialization functions explained in the third part above, both principles implemented by NSCoding require the initialization function of the parent class, which violates the second principle of designated initialization implementation.

what to do?

If you look closely at the definition of initWithCoder: in the NSCoding protocol, you will see a commented-out NS_DESIGNATED_INITIALIZER. Can you find some inspiration?

When implementing the NSCoding protocol, we can explicitly declare initWithCoder: as the designated initialization function (a class can have multiple designated initialization functions, such as UIViewController) to solve the problem immediately, which not only meets the three rules of the designated initialization function, but also meets the three principles of the NSCoding protocol.

VI. Conclusion

The above discussion on the rules of designated initialization can be summarized into two points:

• Convenience initialization functions can only call other initialization methods in their own class
• The designated initialization function is eligible to call the designated initialization function of the parent class

Apple has an official picture that helps us understand these two points:

When we add a designated initialization function to the class we create, we must accurately identify and override all designated initialization functions of the direct parent class, so as to ensure that the initialization process of the entire subclass can cover all member variables in the inheritance chain and get proper initialization.

NS_DESIGNATED_INITIALIZER is a very useful macro that makes full use of the characteristics of the compiler to help us find possible loopholes in the initialization process and enhance the robustness of the code.