学习文章
介绍
随着 Swift 的发展, Objective-C 也保持了跟进.即使还没用Swift开发项目,你一定也从 Objective-C 的 API 中发现了巨大的变化.第一感觉是 API 变得好冗长, API 的排版变得乱七八糟,很多关键字不知所云...
淡定!苹果作为如此成熟且成功的公司,胡来的可能性微乎其微,所以,还得静下心来,学习新东西.
主要介绍三个新特性(可能对于先知们,已经不算新了...):
- Nullability
- Lightweight Generics *
- __kindof
Nullability
Nullability 算是 Objective-C 版的 Optional , nonnull 表示不可为空, 相当于 Swift 中的!, nullable 表示可以为空,相当于 Swift 的?.与下面类似的 API 你一定见过:
@property (nonatomic, strong, nonnull ) Model *m_model;
@property (nonatomic, copy, readonly, nullable) NSArray *m_friendArray;
+ (nullable NSString*)friendWithName: (nonnull NSString*)name;
假如用来修饰一个变量，前面还要加双下划线，放到 block 里面就更加诡异，比如一个 Request 的 start 方法可以写成：
- (void)startWithCompletionBlock:(nullable void (^)(NSError * __nullable error))block;
除 nonnull 和 nullable 外,还有 null_resetttable 来表示 setter nullable , getter nonnull , 举个直观的例子, UIViewController 中的 view 属性:
@property(null_resettable, nonatomic,strong) UIView *view;
它可以被设成 nil，但是调用 getter 时会触发 -loadView 从而创建并返回一个非 nil 的 view。
从 iOS9 SDK 中可以发现，头文件中所有 API 都已经增加了 Nullability 相关修饰符，想了解这个特性的用法，翻几个系统头文件就差不离了。接口中 nullable 的是少数，所以为了防止写一大堆 nonnull，Foundation 还提供了一对儿宏，包在里面的对象默认加 nonnull 修饰符，只需要把 nullable 的指出来就行.
#import <Foundation/Foundation.h>
NS_ASSUME_NONNULL_BEGIN
@interface Model : NSObject
@property (nonatomic, copy, nullable) NSString *m_workingCompany;
@property (nonatomic, copy) NSArray *m_friendArray;
- (nullable NSString*)gayFriend;
@end
NS_ASSUME_NONNULL_END
Nullability 在编译器层面提供了空值的类型检查，在类型不符时给出 warning，方便开发者第一时间发现潜在问题。不过我想更大的意义在于能够更加清楚的描述接口，是主调者和被调者间的一个协议，比多少句文档描述都来得清晰，打个比方：
+ (nullable instancetype)URLWithString:(NSString *)URLString;
NSURL 的这个 API 前面加了 nullable 后，更加显式的指出了这个接口可能因为 URLString 的格式错误而创建失败，使用时自然而然的就考虑到了判空处理。
不仅是属性和方法中的对象，对于局部的对象、甚至 c 指针都可以用带双下划线的修饰符，可以理解成能用 const 关键字的地方都能用 Nullability。
所以 Nullability 总的来说就是，写着丑B，用着舒服 - -
Lightweight Generics (轻量级泛型)
带泛型的容器
有了这个特性,可以指定容器中对象的类型
NSArray<NSString *> *strings = @[@"sun", @"yuan"];
NSDictionary<NSString *, NSNumber *> *mapping = @{@"a": @1, @"b": @2};
返回值的 id 被替换成具体的类型后，令人感动的代码提示也出来了：
假如向泛型容器中加入错误的对象，编译器会不开心的:
自定义泛型类
我们试着写一个Stack的泛型容器类
Stack.h
#import <Foundation/Foundation.h>
@interface Stack<ObjectType> : NSObject
- (void)pushObject: (ObjectType)object;
- (ObjectType)popObhect;
@property (nonatomic, readonly) NSArray<ObjectType> *m_allObjects;
@end
Stack.m
#import "Stack.h"
@interface Stack<ObjectType> ()
@property (nonatomic, strong) NSMutableArray<ObjectType> *m_myObjects;
@property (nonatomic, strong) NSArray< ObjectType> *m_allObjects;
- (void)pushObject: (id)object;
- (id)popObhect;
@end
@implementation Stack
- (instancetype)init {
if (self = [super init]) {
self.m_allObjects = [NSMutableArray array];
self.m_myObjects = [NSMutableArray array];
}
return self;
}
- (void)pushObject: (id)object {
[self.m_myObjects addObject:object];
self.m_allObjects = self.m_myObjects;
}
- (id)popObhect {
id object = [self.m_myObjects lastObject];
[self.m_myObjects removeLastObject];
self.m_allObjects = self.m_myObjects;
return object;
}
@end
代码中的 ObjectType 是传入类型的 placeholder，它只能在 @interface 上定义（类声明、类扩展、Category），如果你喜欢用 T 表示也 ok(就像 Swift 中那样)，这个类型在 @interface 和 @end 区间的作用域有效，可以把它作为入参、出参、甚至内部 NSArray 属性的泛型类型，应该说一切都是符合预期的。
我们还可以给 ObjectType 增加类型限制，比如：
// 只接受 NSNumber * 的泛型
@interface Stack<ObjectType: NSNumber *> : NSObject
// 只接受满足 NSCopying 协议的泛型
@interface Stack<ObjectType: id<NSCopying>> : NSObject
对于多参数的泛型，用逗号隔开，其他都一样，可以参考 NSDictionary 的头文件。
协变性和逆变性
当类支持泛型后，它们的 Type 发生了变化，比如下面三个对象看上去都是 Stack，但实际上属于三个 Type：
Stack *stack; // Stack *
Stack<NSString *> *stringStack; // Stack<NSString *>
Stack<NSMutableString *> *mutableStringStack; // Stack<NSMutableString *>
当其中两种类型做类型转化时，编译器需要知道哪些转化是允许的，哪些是禁止的，比如，默认情况下：
我们可以看到，不指定泛型类型的 Stack 可以和任意泛型类型转化，但指定了泛型类型后，两个不同类型间是不可以强转的，假如你希望主动控制转化关系，就需要使用泛型的协变性和逆变性修饰符了：
__covariant:
协变性(派生程度较大类型分配（赋值）给派生程度较小类型)，子类型可以强转到父类型（里氏替换原则）
__contravariant:
逆变性(派生程度较小类型分配（赋值）给派生程度较大类型)，父类型可以强转到子类型（WTF?）
协变：
@interface Stack<__covariant ObjectType> : NSObject
效果:
逆变：
@interface Stack<__contravariant ObjectType> : NSObject
效果:
协变是非常好理解的，像 NSArray 的泛型就用了协变的修饰符，而逆变我还没有想到有什么实际的使用场景。
__kindof
__kindof 这修饰符还是很实用的，解决了一个长期以来的小痛点，拿原来的 UITableView 的这个方法来说：
- (id)dequeueReusableCellWithIdentifier:(NSString *)identifier;
使用时前面基本会使用 UITableViewCell 子类型的指针来接收返回值，所以这个 API 为了让开发者不必每次都蛋疼的写显式强转，把返回值定义成了 id 类型，而这个 API 实际上的意思是返回一个 UITableViewCell 或 UITableViewCell 子类的实例，于是新的 __kindof 关键字解决了这个问题：
- (__kindof UITableViewCell *)dequeueReusableCellWithIdentifier:(NSString *)identifier;
既明确表明了返回值，又让使用者不必写强转。再举个带泛型的例子，UIView 的 subviews 属性被修改成了：
@property (nonatomic, readonly, copy) NSArray<__kindof UIView *> *subviews;
这样，写下面的代码时就没有任何警告了：
UIButton *button = view.subviews.lastObject;
