iOS指定初始化方法的正确使用姿势

这是小菜去公司实习的第一周,为了好好表现自己,小菜下班后都留在公司继续看书学习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 。

需要注意不同数据源下添加额外初始化动作的时机。

晓雯的这篇文章是来自微信公众号程序员的那点事儿。若有侵权请联系晓雯微信:Pingwen20删除

这是我的一个iOS技术交流群:691040931有兴趣的话可以加入 群里只聊技术 内推 广告忽进 进一次踢一次

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,126评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,254评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,445评论 0 341
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,185评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,178评论 5 371
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,970评论 1 284
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,276评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,927评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,400评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,883评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,997评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,646评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,213评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,204评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,423评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,423评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,722评论 2 345

推荐阅读更多精彩内容