【Objective-C】三个新特性介绍

学习文章

2015 Objective-C 新特性

介绍

随着 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在编译器层面得到支持.png

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 被替换成具体的类型后,令人感动的代码提示也出来了:

泛型提示.jpg

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

类型报错.jpg
自定义泛型类

我们试着写一个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 *>

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

默认转换.png

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

__covariant:
协变性(派生程度较大类型分配(赋值)给派生程度较小类型),子类型可以强转到父类型(里氏替换原则)
__contravariant:
逆变性(派生程度较小类型分配(赋值)给派生程度较大类型),父类型可以强转到子类型(WTF?)

协变:

@interface Stack<__covariant ObjectType> : NSObject

效果:

协变效果.jpg

逆变:

@interface Stack<__contravariant ObjectType> : NSObject

效果:

逆变效果.jpg

协变是非常好理解的,像 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;

下载源码

下载地址

推荐阅读更多精彩内容