iOS开发生涯的初恋：详解Objective-C多项改进
程序员文章站
2022-03-09 23:13:39
...
当众人的目光聚焦在WWDC 2015新推出的Swift 2和iOS 9上时，我的思绪却飘回到办公室书架上。多年前，初入iOS开发时买的Objective-C指导书直至今日还静静地躺在那里，求知若渴地翻动着书页的场景历历在目，心中所想的不是Objective-C的优点，却是它的局限——如今这位老友旧貌换新颜，以往的“局限”不复存在。2015年Objective-C都有哪些提升？这篇文章即将揭晓答案。
The Setup
下面的代码你们一定再熟悉不过了，我们来重温一下吧：
这绝对符合Objective-C完美主义开发者的标准。对它表示的属性，不同人有不同观点。但是，其中仍然存在着一些难以察觉的缺陷。
是否可能返回nil？
除非有现成的文件，或开发者全程都在一旁，否则光凭看是无法获取信息的。
除了UIView之外还有什么？
还是那句话——不确定。也许答案是reflection？ 或许问题可以改成：除了UIView，有可能出现UIView子类吗？
看样子会出现诸多转换（casting）
因为是一队列……东西，知道那东西是什么之后，经过cast后才能利用。
会弱化Swift代码和可读性
很遗憾，Swift支持泛型（generics）就意味着（Objective-C ）只会以optional的AnyObject集合的形式出现。如此一来，开发者要使用该属性就必须在Swift和Objective-C之间进行转换。
Nullability Annotations
单单一个属性就引发了这么多担忧，还挺让人不安的。如果代码本身引发很多质疑，出现error的可能性就大大增加，更别提在广为熟知的Objective-C和语言新秀Swift之间相互调用（interoperability）了。现在有了nullability annotations——我最爱的Objective-C新功能之一，问题就简单多了，编程也会省下很多麻烦。
intent.
现在谈到API，（intent.）可能会，也可能不会返回nil。简而言之，终于不用花费数小时来排除漏洞了。以下有三个选项：
再回到实例属性。假设在运行时迭代这个属性来创建某个用户界面，在相应的位置应该有UIButton和UIView。
但是，天哪！——不论怎么样它们也不应该是nil啊。现在出现如下的信息：
intent.大大提升了Objective-C，而且这个属性也不会在Swift里满满都是optional了。
开发者看看代码就知道有没有nil pointer了，太棒了！
计算机的静态检验和Swift的可用性都得到了提升，最重要的是实现了API的intent通讯。
泛型
……Objective-C开发者们举国欢庆。呜呼，泛型的恩泽终于笼罩大地，这无疑是那些开发者勇士们的功劳。
如果把Cocoa Touch比作孩子们的睡前故事，那么Objective-C就好比是主演，故事书肯定是以上面那段话结尾的。泛型的缺席一直以来是Objective-C开发者心头之痛，而诞生32年之后，Objective-C终于也支持泛型了。2015 WWDC上Swift 2成为了镁光灯下的宠儿，而Objective-C这一巨大的跨越却被忽视了，实在委屈。支持泛型将带来诸多改变，而且都是积极的改变。
现在可以定义属性，下指令给编译器来显示所有UIView：
向属性强加UIView之外的东西时，编译器会报错。而且如今不用做大量头痛的转换（cast）了。
Objective-C支持泛型对Swift而言也是好消息。上次更新时，我们让Swift知道对象不应该是optional的，现在Swift还知道它们是UIViews，如此一来含混不清的AnyObject声明就不需要了。如今的Objective-C可以像C#、C++、Swift等语言一样通过<>括号来表示类型了。虽然通常是对协议表示一致性（conformance），但编译器知道何时、何地以及如何运用它们，且运用是经过推理的。
再进一步，可以用参数来表示扩展（extensions）、类别（categories）和类（classes），好处不仅仅体现在集合（collections）上。泛型的强大体现在整个Objective-C之中，集合仅仅是结果而已。举个例子，看看NSDictionary，开发者肯定会偷着乐吧：
刚开始知道类型擦除（type erasure）是为了这个的时候，我有点儿不满意，但考虑到老旧的Objective-C程序堆积在一起的问题，也就释怀了。
类型擦除（type erasure）不但能实现二进制兼容，而且不改变Objective-C的执行时间。所以亲爱的开发者们，C#的泛型的确胜过其他语言，皱皱眉头，发几句牢骚就算了，日子还得继续呢。
KindOf Types
啊，这是最后一部分重要内容。再次调用之前定义的属性，就会显示UIView。判断里面包含着views和buttons是再正常不过的事。
这种情况下，添加如下代码会发生什么呢？
啊，编译器警告。
这就对啦，因为即便可以在这个属性里插入一个button，就算可以假设是个UIView，button也不一定没有经过转换。
新的KindOf特性能够轻松解决这种始料未及的情况。我们再回到实例属性上：
实际上我们已经告诉编译器：属性及其集合会出现一些UIView。这样在类型协议里显示更多我们之前看不到的信息。其本质向下转型（downcasting）。
这意味着上述代码编译没什么问题，因为编译器知道集合里肯定会出现一个button。
现在那些担忧就都解释得清了。
虽然不喜欢Swift的人可能会刻意夸大Objective-C的优点，但如今两种语言实现了互相调用，这是Objective-C所有提升的最大价值所在，我们应该心存感激。
毋庸置疑，Objective-C的确比以往更加强大。
总结
对我来说，Objective-C是开发生涯中的初恋，相比其他语言，它是那么与众不同——直到今天都是如此，它的好、它的坏都让我欲罢不能。虽然如今Swift正以迅雷不及掩耳之势征服着我的心，我还是希望Objective-C陪伴在身边。
Objective-C的提升能够帮助开发者写出更好的代码，这是好事。而且这些优势已经在Foundation中随处可见了。
文章来源：Medium
The Setup
下面的代码你们一定再熟悉不过了，我们来重温一下吧：
@property (strong, nonatomic) NSArray *someViews;
这绝对符合Objective-C完美主义开发者的标准。对它表示的属性，不同人有不同观点。但是，其中仍然存在着一些难以察觉的缺陷。
是否可能返回nil？
除非有现成的文件，或开发者全程都在一旁，否则光凭看是无法获取信息的。
除了UIView之外还有什么？
还是那句话——不确定。也许答案是reflection？ 或许问题可以改成：除了UIView，有可能出现UIView子类吗？
看样子会出现诸多转换（casting）
因为是一队列……东西，知道那东西是什么之后，经过cast后才能利用。
会弱化Swift代码和可读性
很遗憾，Swift支持泛型（generics）就意味着（Objective-C ）只会以optional的AnyObject集合的形式出现。如此一来，开发者要使用该属性就必须在Swift和Objective-C之间进行转换。
Nullability Annotations
单单一个属性就引发了这么多担忧，还挺让人不安的。如果代码本身引发很多质疑，出现error的可能性就大大增加，更别提在广为熟知的Objective-C和语言新秀Swift之间相互调用（interoperability）了。现在有了nullability annotations——我最爱的Objective-C新功能之一，问题就简单多了，编程也会省下很多麻烦。
intent.
现在谈到API，（intent.）可能会，也可能不会返回nil。简而言之，终于不用花费数小时来排除漏洞了。以下有三个选项：
- nullable — Think UIView?
- nonnull — Think UIView
- null_unspecified — Think UIView!
再回到实例属性。假设在运行时迭代这个属性来创建某个用户界面，在相应的位置应该有UIButton和UIView。
但是，天哪！——不论怎么样它们也不应该是nil啊。现在出现如下的信息：
@property (strong, nonatomic, nonnull) NSArray *someViews;
intent.大大提升了Objective-C，而且这个属性也不会在Swift里满满都是optional了。
开发者看看代码就知道有没有nil pointer了，太棒了！
计算机的静态检验和Swift的可用性都得到了提升，最重要的是实现了API的intent通讯。
泛型
……Objective-C开发者们举国欢庆。呜呼，泛型的恩泽终于笼罩大地，这无疑是那些开发者勇士们的功劳。
如果把Cocoa Touch比作孩子们的睡前故事，那么Objective-C就好比是主演，故事书肯定是以上面那段话结尾的。泛型的缺席一直以来是Objective-C开发者心头之痛，而诞生32年之后，Objective-C终于也支持泛型了。2015 WWDC上Swift 2成为了镁光灯下的宠儿，而Objective-C这一巨大的跨越却被忽视了，实在委屈。支持泛型将带来诸多改变，而且都是积极的改变。
现在可以定义属性，下指令给编译器来显示所有UIView：
@property (strong, nonatomic, nonnull) NSArray<UIView *> *someViews;
向属性强加UIView之外的东西时，编译器会报错。而且如今不用做大量头痛的转换（cast）了。
Objective-C支持泛型对Swift而言也是好消息。上次更新时，我们让Swift知道对象不应该是optional的，现在Swift还知道它们是UIViews，如此一来含混不清的AnyObject声明就不需要了。如今的Objective-C可以像C#、C++、Swift等语言一样通过<>括号来表示类型了。虽然通常是对协议表示一致性（conformance），但编译器知道何时、何地以及如何运用它们，且运用是经过推理的。
再进一步，可以用参数来表示扩展（extensions）、类别（categories）和类（classes），好处不仅仅体现在集合（collections）上。泛型的强大体现在整个Objective-C之中，集合仅仅是结果而已。举个例子，看看NSDictionary，开发者肯定会偷着乐吧：
@interface NSDictionary<KeyType, ObjectType> (Lookup) - (nullable ObjectType)objectForKey:(KeyType)aKey; @end
刚开始知道类型擦除（type erasure）是为了这个的时候，我有点儿不满意，但考虑到老旧的Objective-C程序堆积在一起的问题，也就释怀了。
类型擦除（type erasure）不但能实现二进制兼容，而且不改变Objective-C的执行时间。所以亲爱的开发者们，C#的泛型的确胜过其他语言，皱皱眉头，发几句牢骚就算了，日子还得继续呢。
KindOf Types
啊，这是最后一部分重要内容。再次调用之前定义的属性，就会显示UIView。判断里面包含着views和buttons是再正常不过的事。
这种情况下，添加如下代码会发生什么呢？
[self.someViews[0] addTarget:self action:selector(aMethod:) forControlEvents:UIControlEventTouchUpInside];
啊，编译器警告。
这就对啦，因为即便可以在这个属性里插入一个button，就算可以假设是个UIView，button也不一定没有经过转换。
新的KindOf特性能够轻松解决这种始料未及的情况。我们再回到实例属性上：
@property (strong, nonatomic, nonnull) NSArray<__kindof UIView *> *someViews;
实际上我们已经告诉编译器：属性及其集合会出现一些UIView。这样在类型协议里显示更多我们之前看不到的信息。其本质向下转型（downcasting）。
这意味着上述代码编译没什么问题，因为编译器知道集合里肯定会出现一个button。
现在那些担忧就都解释得清了。
虽然不喜欢Swift的人可能会刻意夸大Objective-C的优点，但如今两种语言实现了互相调用，这是Objective-C所有提升的最大价值所在，我们应该心存感激。
毋庸置疑，Objective-C的确比以往更加强大。
总结
对我来说，Objective-C是开发生涯中的初恋，相比其他语言，它是那么与众不同——直到今天都是如此，它的好、它的坏都让我欲罢不能。虽然如今Swift正以迅雷不及掩耳之势征服着我的心，我还是希望Objective-C陪伴在身边。
Objective-C的提升能够帮助开发者写出更好的代码，这是好事。而且这些优势已经在Foundation中随处可见了。
（翻译/张新慧 审校/唐小引）
文章来源：Medium
上一篇： Objective-C 开发中最糟糕的 13 件事
下一篇： 基于ruby Mechanize的爬虫