2015年Objective-C有哪些新功能？

 

     虽然6月8日苹果WWDC大会之后，所有iOS开发者的眼光都被Swift 2和iOS 9吸引了，而iOS开发老语言Objective-C的受欢迎度却大不如从前。

     虽然iOS开发出了新的swift语言，但是绝大部分老iOS开发从业者及新入门者，都没有放弃对Objective-C语言的使用和学习。所以苹果公司在今天也对Objective-C做了一些升级，以往这门语言的使用“局限”将不复存在。下面我们就一起来看下，今年Objective-C语言做了升级。

 

The Setup

iOS开发人员，对下面的代码一定再熟悉不过了，我们来重温一下吧：

 

@property(strong, nonatomic) NSArray *someViews;

这绝对符合Objective-C完美主义开发者的标准。对它表示的属性，不同人有不同观点。但是，其中仍然存在着一些难以察觉的缺陷。

 

是否可能返回nil？

 

除非有现成的文件，或开发者全程都在一旁，否则光凭看是无法获取信息的。

 

除了UIView之外还有什么？

 

还是那句话――不确定。也许答案是reflection？ 或许问题可以改成：除了UIView，有可能出现UIView子类吗？

 

看样子会出现诸多转换（casting）

 

因为是一队列……东西，知道那东西是什么之后，经过cast后才能利用。

 

会弱化Swift代码和可读性

 

很遗憾，Swift语言支持泛型（generics）就意味着（Objective-C ）只会以optional的AnyObject集合的形式出现。如此一来，开发者要使用该属性就必须在Swift和Objective-C之间进行转换。

 

NullabilityAnnotations

仅仅是一个属性就引发了这么多的担忧，还挺让人不安的。如果代码本身引发很多质疑，出现error的可能性就大大增加，更别提在广为熟知的Objective-C和语言新秀Swift之间相互调用（interoperability）了。现在Objective-C有了nullability annotations这个新功能，问题就简单多了，也可为编程剩下很多麻烦。

 

intent.

 

现在谈到API，（intent.）可能会，也可能不会返回nil，但不管怎样，终于不用花费数小时来排除漏洞了。以下有三个选项：

 

nullable ― ThinkUIView?

nonnull ― ThinkUIView

null_unspecified― Think UIView!

再回到实例属性。假设在运行时迭代这个属性来创建某个用户界面，在相应的位置应该有UIButton和UIView。

intent.大大提升了Objective-C，而且这个属性也不会在Swift里满满都是optional了。计算机的静态检验和Swift的可用性都得到了提升，最重要的是实现了API的intent通讯。

 

泛型

泛型的缺席一直以来是Objective-C开发者心头之痛，而在这门语言诞生32年之后，终于也支持泛型了。对于Objective-C来说，支持泛型将带来诸多改变，而且都是积极的改变。

 

现在可以定义属性，下指令给编译器来显示所有UIView：

 

@property(strong, nonatomic, nonnull) NSArray<UIView *> *someViews;

向属性强加UIView之外的东西时，编译器会报错。而且如今不用做大量头痛的转换（cast）了。

      虽然Objective-C语言和swift语言看起来像iOS开发平台两个对立的语言，但Objective-C支持泛型确实对Swift而言也是好消息。Objective-C上次更新时，让Swift知道对象不应该是optional的，现在Swift还知道它们是UIViews，如此一来含混不清的AnyObject声明就不需要了。如今的Objective-C可以像C#、C++、Swift等语言一样通过<>括号来表示类型了。虽然通常是对协议表示一致性（conformance），但编译器知道何时、何地以及如何运用它们，且运用是经过推理的。

 

泛型的强大体现在整个Objective-C之中，可以用参数来表示扩展（extensions）、类别（categories）和类（classes），好处不仅仅体现在集合（collections）上，集合仅仅是结果而已。举个例子，看看NSDictionary，开发者肯定会偷着乐吧：

 

@interfaceNSDictionary<KeyType, ObjectType> (Lookup)

- (nullableObjectType)objectForKey:(KeyType)aKey;

@end

刚开始知道类型擦除（typeerasure）是为了这个的时候，我有点儿不满意，但考虑到老旧的Objective-C程序堆积在一起的问题，也就释怀了。类型擦除（type erasure）不但能实现二进制兼容，而且不改变Objective-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的确比以往更加强大。

 

总结

    虽然swift语言不断升级、变强，越来越多的iOS开发者开始使用swift语言了，但是还是有绝大部分的人在使用、学习swift的同时，仍在继续研究Objective-C语言，也还有很多初学者正在纠结到底是学swift还是Objective-C。相信，随着Objective-C的不断升级，将让大家对这两门语言的选择上，更加“欲摆不能”。不过这是好事，既然都好，那就让自己同时驾驭这两门语言吧。