2015 Objective-C 三大新特性

1434333997915314.jpg

Overview

自 WWDC 2015 推出和开源 Swift 2.0 后,大家对 Swift 的热情又一次高涨起来,在羡慕创业公司的朋友们大谈 Swift 新特性的同时,也有很多像我一样工作上依然需要坚守着 Objective-C 语言的开发者们。今年的 WWDC 中介绍了几个 Objective-C 语言的新特性,还是在“与 Swift 协同工作”这种 Topic 里讲的,越发凸显这门语言的边缘化了,不过有新特性还是极好的,接下来,本文将介绍下面三个主要的新特性:

  • Nullability

  • Lightweight Generics *

  • __kindof

Nullability

然而 Nullability 并不算新特性了,从上一个版本的 llvm 6.1 (Xcode 6.3) 就已经支持。这个简版的 Optional ,没有 Swift 中 ? 和 ! 语法糖的支持,在 Objective-C 中就显得非常啰嗦了:

1
2
3
@property (nonatomic, strong, nonnull) Sark *sark;
@property (nonatomic, copy, readonly, nullable) NSArray *friends;
+ (nullable NSString *)friendWithName:(nonnull NSString *)name;

假如用来修饰一个变量,前面还要加双下划线,放到 block 里面就更加诡异,比如一个 Request 的 start 方法可以写成:

1
- (void)startWithCompletionBlock:(nullable void (^)(NSError * __nullable error))block;

除了这俩外,还有个 null_resettable 来表示 setter nullable,但是 getter nonnull,绕死了,最直观例子就是 UIViewController 中的 view 属性:

1
@property (null_resettable, nonatomic, strong) UIView *view;

它可以被设成 nil,但是调用 getter 时会触发 -loadView 从而创建并返回一个非 nil 的 view。

从 iOS9 SDK 中可以发现,头文件中所有 API 都已经增加了 Nullability 相关修饰符,想了解这个特性的用法,翻几个系统头文件就差不离了。接口中 nullable 的是少数,所以为了防止写一大堆 nonnull,Foundation 还提供了一对儿宏,包在里面的对象默认加 nonnull 修饰符,只需要把 nullable 的指出来就行,黑话叫 Audited Regions:

1
2
3
4
5
6
7
NS_ASSUME_NONNULL_BEGIN
@interface Sark : NSObject
@property (nonatomic, copy, nullable) NSString *workingCompany;
@property (nonatomic, copy) NSArray *friends;
- (nullable NSString *)gayFriend;
@end
NS_ASSUME_NONNULL_END

Nullability 在编译器层面提供了空值的类型检查,在类型不符时给出 warning,方便开发者第一时间发现潜在问题。不过我想更大的意义在于能够更加清楚的描述接口,是主调者和被调者间的一个协议,比多少句文档描述都来得清晰,打个比方:

1
+ (nullable instancetype)URLWithString:(NSString *)URLString;

NSURL 的这个 API 前面加了 nullable 后,更加显式的指出了这个接口可能因为 URLString 的格式错误而创建失败,使用时自然而然的就考虑到了判空处理。

不仅是属性和方法中的对象,对于局部的对象、甚至 c 指针都可以用带双下划线的修饰符,可以理解成能用 const 关键字的地方都能用 Nullability。

所以 Nullability 总的来说就是,写着丑B,用着舒服 - -

Lightweight Generics

Lightweight Generics 轻量级泛型,轻量是因为这是个纯编译器的语法支持(llvm 7.0),和 Nullability 一样,没有借助任何 objc runtime 的升级,也就是说,这个新语法在 Xcode 7 上可以使用且完全向下兼容(更低的 iOS 版本)

带泛型的容器

这无疑是本次最重大的改进,有了泛型后终于可以指定容器类中对象的类型了:

1
2
NSArray<nsstring *> *strings = @[@ "sun" , @ "yuan" ];
NSDictionary<nsstring *, nsnumber *> *mapping = @{@ "a" : @1, @ "b" : @2};</nsstring *, nsnumber *></nsstring *>

返回值的 id 被替换成具体的类型后,令人感动的代码提示也出来了:

blob.png

假如向泛型容器中加入错误的对象,编译器会不开心的:

blob.png

系统中常用的一系列容器类型都增加了泛型支持,甚至连 NSEnumerator 都支持了,这是非常 Nice 的改进。和 Nullability 一样,我认为最大的意义还是丰富了接口描述信息,对比下面两种写法:

1
2
@property (readonly) NSArray *imageURLs;
@property (readonly) NSArray<nsurl *> *imageURLs;</nsurl *>

不用多想就清楚下面的数组中存的是什么,避免了 NSString 和 NSURL 的混乱。

自定义泛型类

比起使用系统的泛型容器,更好玩的是自定义一个泛型类,目前这里还没什么文档,但拦不住我们写测试代码,假设我们要自定义一个 Stack 容器类:

1
2
3
4
5
@interface Stack<objecttype> : NSObject
- (void)pushObject:(ObjectType)object;
- (ObjectType)popObject;
@property (nonatomic, readonly) NSArray<objecttype> *allObjects;
@end</objecttype></objecttype>

这个 ObjectType 是传入类型的 placeholder,它只能在 @interface 上定义(类声明、类扩展、Category),如果你喜欢用 T 表示也 ok,这个类型在 @interface 和 @end 区间的作用域有效,可以把它作为入参、出参、甚至内部 NSArray 属性的泛型类型,应该说一切都是符合预期的。我们还可以给 ObjectType 增加类型限制,比如:

1
2
3
4
// 只接受 NSNumber * 的泛型
@interface Stack<objecttype: nsnumber *> : NSObject
// 只接受满足 NSCopying 协议的泛型
@interface Stack<objecttype: id<nscopying>> : NSObject</objecttype: id<nscopying></objecttype: nsnumber *>

若什么都不加,表示接受任意类型 ( id );当类型不满足时编译器将产生 error。

实例化一个 Stack,一切工作正常:

blob.png

对于多参数的泛型,用逗号隔开,其他都一样,可以参考 NSDictionary 的头文件。

协变性和逆变性

当类支持泛型后,它们的 Type 发生了变化,比如下面三个对象看上去都是 Stack,但实际上属于三个 Type:

1
2
3
Stack *stack;  // Stack *
Stack<nsstring *> *stringStack;  // Stack<nsstring *>
Stack<nsmutablestring *> *mutableStringStack;  // Stack<nsmutablestring *></nsmutablestring *></nsmutablestring *></nsstring *></nsstring *>

当其中两种类型做类型转化时,编译器需要知道哪些转化是允许的,哪些是禁止的,比如,默认情况下:

blob.png

我们可以看到,不指定泛型类型的 Stack 可以和任意泛型类型转化,但指定了泛型类型后,两个不同类型间是不可以强转的,假如你希望主动控制转化关系,就需要使用泛型的协变性逆变性修饰符了:

__covariant - 协变性,子类型可以强转到父类型(里氏替换原则)

__contravariant - 逆变性,父类型可以强转到子类型(WTF?)

协变:

1
@interface Stack<__covariant ObjectType> : NSObject

效果:

blob.png

逆变:

1
@interface Stack<__contravariant ObjectType> : NSObject

效果:

blob.png

协变是非常好理解的,像 NSArray 的泛型就用了协变的修饰符,而逆变我还没有想到有什么实际的使用场景。

__kindof

__kindof 这修饰符还是很实用的,解决了一个长期以来的小痛点,拿原来的 UITableView 的这个方法来说:

1
- (id)dequeueReusableCellWithIdentifier:(NSString *)identifier;

使用时前面基本会使用 UITableViewCell 子类型的指针来接收返回值,所以这个 API 为了让开发者不必每次都蛋疼的写显式强转,把返回值定义成了 id 类型,而这个 API 实际上的意思是返回一个 UITableViewCell 或 UITableViewCell 子类的实例,于是新的 __kindof 关键字解决了这个问题:

1
- (__kindof UITableViewCell *)dequeueReusableCellWithIdentifier:(NSString *)identifier;

既明确表明了返回值,又让使用者不必写强转。再举个带泛型的例子,UIView 的 subviews 属性被修改成了:

1
@property (nonatomic, readonly, copy) NSArray<__kindof UIView *> *subviews;

这样,写下面的代码时就没有任何警告了:

1
UIButton *button = view.subviews.lastObject;

Where to go

有了上面介绍的这些新特性以及如 instancetype 这样的历史更新,Objective-C 这门古老语言的类型检测和类型推断终于有所长进,现在不论是接口还是代码中的 id 类型都越来越少,更多潜在的类型错误可以被编译器的静态检查发现。

同时,个人感觉新版的 Xcode 对继承链构造器的检测也加强了,NS_DESIGNATED_INITIALIZER 这个宏并不是新面孔,可以使用它标志出像 Swift 一样的指定构造器和便捷构造器。

最后,附上一段用上了所有新特性的代码,Swift 是发展趋势,如果你暂时依然要写 Objective-C 代码,把所有新特性都用上,或许能让你到新语言的迁移更无痛一点。

blob.png

References

已标记关键词 清除标记
相关推荐
中文名: Objective-C基础教程 作者: Mark Dalrymple Scott Knaster译者: 高朝勤 杨越 刘霞图书 分类: 软件 资源格式: PDF 版本: 扫描版 出版社: 人民邮电出版社 书号: ISBN: 9787115208774 发行时间: 2009年08月 地区: 大陆 语言: 简体中文 简介: 内容简介 Objective-C是扩展C的面向对象编程语言,也是iPhone开发用到的主要语言。本书结合理论知识与示例程序,全面而系统地讲述Objective-C编程的相关内容,包括Objective-C在C的基础上引入的特性和Cocoa工具包的功能及其中的框架,以及继承、复合、源文件组织等众多重要的面向对象编程技术。附录中还介绍了如何从其他语言过渡到Objective-C。   本书适合各类开发人员阅读。 内容截图 目录: 第1章 启程.1 1.1 预备知识1 1.2 历史背景1 1.3 内容简介2 1.4 小结3 第2章 对C的扩展4 2.1 最简单的Objective-C程序4 2.2 解构HelloObjective-C程序7 2.2.1 #import7 2.2.2 NSLog()和@"字符串"8 2.3 布尔类型10 2.3.1 BOOL强大的实用功能11 2.3.2 比较13 2.4 小结14 第3章 面向对象编程基础知识15 3.1 间接15 3.1.1 变量与间接16 3.1.2 使用文件名的间接18 3.2 在面向对象的编程中使用间接24 3.2.1 过程式编程24 3.2.2 实现面向对象编程29 3.3 学习有关的术语33 3.4 Objective-C中的OOP34 3.4.1 @interface部分34 3.4.2 @implementation部分38 3.4.3 实例化对象40 3.4.4 扩展Shapes-Object41 3.5 小结43 第4章 继承45 4.1 为何使用继承45 4.2 继承语法48 4.3 继承的工作机制51 4.3.1 方法调度51 4.3.2 实例变量53 4.4 重写方法55 4.5 小结57 第5章 复合58 5.1 什么是复合58 5.1.1 Car程序58 5.1.2 自定义NSLog()59 5.2 存取方法62 5.2.1 设置发动机的属性64 5.2.2 设置轮胎的属性64 5.2.3 跟踪汽车的变化66 5.3 扩展CarParts程序67 5.4 复合还是继承68 5.5 小结69 第6章 源文件组织70 6.1 拆分接口和实现部分70 6.2 拆分Car程序73 6.3 使用跨文件依赖关系75 6.3.1 重编译须知75 6.3.2 让汽车开动77 6.3.3 导入和继承79 6.4 小结80 第7章 深入了解Xcode82
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页