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的不斷升級，將讓大家對這兩門語言的選擇上，更加“欲擺不能”。不過這是好事，既然都好，那就讓自己同時駕馭這兩門語言吧。