解析Swift 3.0預(yù)告的新變化

　　原因

　　這個源于一個編號為 SE-0005 的提案，并且已經(jīng)審核通過。這個方案的提出，源于這樣一個痛點。 Swift 應(yīng)用于 iOS App 開發(fā)，就免不了會依賴于原生的 Cocoa Touch 庫。而由于歷史原因，大家也都知道， iOS 原生庫大多時基于 Objc 來實現(xiàn)的。所以他們的編碼規(guī)范也都遵循著 Objc 的規(guī)范，諸如函數(shù)，方法的命名規(guī)則這些，都有自己的一套標準。

　　而 Swift 3.0 也發(fā)布了自己的 API 設(shè)計規(guī)范，同時 Objc 也有自己的設(shè)計規(guī)范， 這樣一來我們使用 Swift 開發(fā) iOS App 的時候，其實總是在游走于兩套規(guī)范的 API 之間，對開發(fā)者的體驗嘛，就不是很好了。

　　例子

　　咱們用一個實際的例子來說明這個問題。 比如 NSString 有這樣一個方法：

　　letcontent = listItemView.text.stringByTrimmingCharactersInSet（

　　NSCharacterSet.whitespaceAndNewlineCharacterSet（））

　　stringByTrimmingCharactersInSet 會剪掉字符串頭尾中的某些字符。從這個方法名中，明顯的可以看出它是以 Objc 規(guī)范來命名的。

　　如果以 Swift 的編碼規(guī)范，這個方法其實應(yīng)該這樣命名：

　　letcontent = listItemView.text.trimming（.whitespaceAndNewlines）

　　從這里可以看出，objc 的命名方式，很多會把函數(shù)的返回值類型，以及參數(shù)類型都包含在函數(shù)名里面。比如我們上面的stringByTrimmingCharactersInSet 方法。但這和 Swift 命名規(guī)則就不同了。而且隨著 Swift 規(guī)范的清晰，這個問題就越來越凸顯出來了。

　　所以 Swift 3.0 才會將這個問題提上日程，并在這個版本中準備解決這個問題。

　　規(guī)則

　　解決這個問題，肯定不能手動的替換。因為系統(tǒng)庫的方法實在太多了，所以就需要總結(jié)出一系列替換規(guī)則。根據(jù)這些規(guī)則將相應(yīng)的標識替換完成。

　　那么 Swift 具體是怎么做的呢， 咱們來了解一下。

　　擴大 swift_name 編譯屬性的應(yīng)用范圍- 這個涉及到 Swift 底層的概念，當我們將 Objc 的 API 導(dǎo)入到 Swift 的時候，我們是可以指定一個編譯屬性swift_name 的。而這個編譯屬性，可以將 Objc 中的標識名稱在 Swift 中以不同的名字表現(xiàn)出來。但在之前的版本中，這個編譯屬性只能對枚舉項和工廠方法有效，這次將會擴大它的范圍。

　　去除多余的類型名稱- Objc 的編碼規(guī)范中，會建議在方法名稱中將參數(shù)名和類型也表示出來，而這個在 Swift 中就是多余的，我們前面那個例子也演示了。這個也是著重處理的點。

　　添加默認參數(shù)- 對于 Objc 需要默認參數(shù)的地方，會在 Swift 中添加上默認參數(shù)，比如一些選項參數(shù)：

　　NSJSONSerialization.JSONObjectWithData（data， options： NSJSONReadingOptions.AllowFragments）

　　這個 option 參數(shù)就會提供默認參數(shù)。

　　添加第一個參數(shù)的參數(shù)標簽- 為方法的第一個參數(shù)添加合適的參數(shù)標簽。

　　在布爾屬性前面加上 is- 在最新的 Swift 規(guī)范中，需要在布爾屬性前面加上 is， 而 Objc 規(guī)范恰巧不建議使用 is，所以在 Swift 3 中會將 Objc 遷移過來的布爾屬性，按照 Swift 規(guī)范來進行修改?？梢詤⒖?Swift 規(guī)范中關(guān)于布爾屬性的部分內(nèi)容。

　　值類型變成小寫- 會將 Objc 的屬性值以小寫開頭， 比如 URLHandler 會變?yōu)?urlHandler.

　　下面是一個官方文檔中給出的轉(zhuǎn)換的例子：

　　classUIBezierPath： NSObject， NSCopying， NSCoding{

　　convenience init（ovalInRect： CGRect）

　　funcmoveToPoint（_： CGPoint）

　　funcaddLineToPoint（_： CGPoint）

　　funcaddCurveToPoint（_： CGPoint， controlPoint1： CGPoint， controlPoint2： CGPoint）

　　funcaddQuadCurveToPoint（_： CGPoint， controlPoint： CGPoint）

　　funcappendPath（_： UIBezierPath）

　　funcbezierPathByReversingPath（）-》 UIBezierPath

　　funcapplyTransform（_： CGAffineTransform）

　　varempty： Bool{ get}

　　funccontainsPoint（_： CGPoint）-》 Bool

　　funcfillWithBlendMode（_： CGBlendMode， alpha： CGFloat）

　　funcstrokeWithBlendMode（_： CGBlendMode， alpha： CGFloat）

　　funccopyWithZone（_： NSZone）-》 AnyObject

　　funcencodeWithCoder（_： NSCoder）

　　}

　　轉(zhuǎn)換后：

　　classUIBezierPath： NSObject， NSCopying， NSCoding{

　　convenience init（ovalIn rect： CGRect）

　　funcmove（to point： CGPoint）

　　funcaddLine（to point： CGPoint）

　　funcaddCurve（to endPoint： CGPoint， controlPoint1 controlPoint1： CGPoint， controlPoint2 controlPoint2： CGPoint）

　　funcaddQuadCurve（to endPoint： CGPoint， controlPoint controlPoint： CGPoint）

　　funcappend（_bezierPath： UIBezierPath）

　　funcreversing（）-》 UIBezierPath

　　funcapply（_transform： CGAffineTransform）

　　varisEmpty： Bool{ get}

　　funccontains（_point： CGPoint）-》 Bool

　　funcfill（_blendMode： CGBlendMode， alpha alpha： CGFloat）

　　funcstroke（_blendMode： CGBlendMode， alpha alpha： CGFloat）

　　funccopy（with zone： NSZone = nil）-》 AnyObject

　　funcencode（with aCoder： NSCoder）

　　}

　　是不是感覺方法名清晰很多呢。

　　總結(jié)

　　以上就是 Swift 3 對 Objc 依賴庫中的優(yōu)化了，這次優(yōu)化后，我們以后在用 Swift 來開發(fā) iOS App 的時候，就不會再混合兩種代碼風格啦。