小菜编程成长记之 《Designated Initializer》
这是小菜去公司实习的第一周,为了好好表现自己,小菜下班后都留在公司继续看书学习iOS。这一天小菜在看某个开源代码的时候发现了一个之前没有见过的宏 NS_DESIGNATED_INITIALIZER。
在经过两个个小时的百度之后,小菜了解到,这个宏可以指定类的初始化方法。
撸完这段后,小菜迫不及待的提交了代码。
首先来看下这个两个宏NS_DESIGNATED_INITIALIZER、NS_UNAVAILABLE,他们是什么,可以用来干什么?
NS_DESIGNATED_INITIALIZER : 指定构造器
NS_UNAVAILABLE : 禁用该初始化方法
要知道,当我们在团队合作的过程中经常会设计一些类给别人使用,如果我们设计的类提供了多个初始化方法,调用者往往会手足无措,不知道哪一个才是正确的初始化方法。对此,苹果提供了NS_DESIGNATED_INITIALIZER、NS_UNAVAILABLE 。通过这两个宏,我们可以约束定义方式,使接口的描述更加清晰。
NS_DESIGNATED_INITIALIZER
对于多个 init 方法,苹果给出了一个调用顺序,而我们也应该遵守这种调用顺序,以确保无论外部调用者从哪个入口进入,都能够正确的初始化:
通过这张图,我们可以看到指定构造器是 initWithTitle:date:,如果调用者通过 init 或者 initWithTitle: ,最后都会调用 initWithTitle:date: 方法,接着调用父类的 init 并初始化相应的变量。可以看到无论外部调用者调用那种初始化方法,最终都会调用 Designed initializer。
那么如何来告诉外部调用者,initWithTitle: 是一个 Designed initializer 呢?答案就是使用 NS_DESIGNATED_INITIALIZER
- (instancetype)initWithTitle:(NSString *)atitle date:(NSDate *)aDate NS_DESIGNATED_INITIALIZER;
Case Study
接下来让我们通过几个 Case Study 来更加深入的了解下 Designed initializer
Case 1 :Designated Initializer Ordering
//MessagePromptView.h @interface MessagePromptView : UIView - (instancetype)initWithMessage:(NSString *)message NS_DESIGNATED_INITIALIZER; @end //MessagePromptView.m @interface MessagePromptView () @property (nonatomic, copy) NSString *message; @end @implementation MessagePromptView - (instancetype)initWithMessage:(NSString *)message{ if (self = [super initWithFrame:CGRectZero]) { _message = message; } return self; } - (instancetype)initWithFrame:(CGRect)frame{ return [self initWithMessage:nil]; } - (instancetype)initWithCoder:(NSCoder *)aDecoder{ return [self initWithMessage:nil]; } @end
基于以上 Case1 的代码,我们可以得出以下结论:
调用父类链中或者本类的任何指定构造器都是有效的,并且可以保证执行顺序是从最远的祖先类([NSObject init])到最近的子孙类([MessagePromptView initWithMessage:])。在下面三个图中,清晰的展示了分别用以下的指定构造器初始化方法时的执行顺序: initWithMessage:、initWithFrame: 、init。
case 2 : Example bug in UIViewController subclass
在 case 2中,演示了当不小心违反以下规则时的情景:不能重写或者调用非直属父类的指定构造器初始化方法。类似的,也就是我们不应该在 UIViewController 的子类中,重写或者调用 [NSObject init]。
//MessagePromptViewController.h @interface MessagePromptViewController : UIViewController @property (nonatomic, copy) NSString *message; @end //MessagePromptViewController.m @implementation MessagePromptViewController - (instancetype)init{ if (self = [super init]) { _message = @"message"; } return self; } @end
在这个以上代码中,如果我们使用 [[MessagePromptViewController alloc] init] 初始化一个控制器,那是没问题的,但是,如果用 [[MessagePromptViewController alloc] initWithNibName:nil bundle:nil]; 来初始化,那么 MessagePromptViewController 中的 init 部分代码将永远不会执行到。
调用顺序如下:
当有 MessagePromptViewController 的子类 SubclassController重写了initWithNibName:bundle:时:
//SubclassController.h @interface SubclassController : MessagePromptViewController @end @implementation SubclassController - (instancetype)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil{ if (self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]) { self.message = @"subclass"; } return self; } @end
对于子类SubclassController,如果用 [[SubclassController alloc] initWithNibName:nil bundle:nil]; 初始化,那么 MessagePromptViewController 中的初始化方法也不会执行到。如果用 [[SubclassController alloc] initWithNibName:nil bundle:nil]; 初始化,虽然所有的初始化方法都会被调用,但是初始化方法执行的先后顺序是错的:message的值先在子类中被赋值为"subclass",接着又在父类中被重新赋值为"message"。
调用顺序如下:
NS_UNAVAILABLE
在定义初始化方法时,除了能够用 NS_DESIGNATED_INITIALIZER 标记以外,还可以使用 NS_UNAVAILABLE。NS_DESIGNATED_INITIALIZER 是用于指定初始化方法,NS_UNAVAILABLE 则是用禁用其标记的初始化方法。
使用 Designated Initializer 的原则
每个类的正确初始化过程应当是按照从子类到父类的顺序,依次调用每个类的 Designated Initializer
而且用父类的 Designated Initializer 初始化一个子类对象,也需要遵从这个过程。
如果子类指定了新的初始化器,那么在这个初始化器内部必须调用父类的 Designated Initializer。并且需要重写父类的 Designated Initializer,将其指向子类新的初始化器。
可以不自定义 Designated Initializer ,重写父类的 Designated Initializer ,但需要调用直接父类的 Designated Initializer 。
如果有多个 Secondary initializers (次要初始化器),它们之间可以任意调用,但最后必须指向 Designated Initializer。在 Secondary initializers 内不能直接调用父类的初始化器。
如果有多个不同数据源的 Designated Initializer,那么不同数据源下的 Designated Initializer 应该调用相应的 [super (designated initializer)]。
如果父类没有实现相应的方法,则需要根据实际情况来决定是给父类补充一个新的方法还是调用父类其他数据源的 Designated Initializer。比如 UIView 的 initWithCoder 调用的是 NSObject 的 init 。
需要注意不同数据源下添加额外初始化动作的时机。