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

　　原因

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

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

　　例子

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

　　letcontent = listItemView.text.stringByTrimmingCharactersInSet（

　　NSCharacterSet.whitespaceAndNewlineCharacterSet（））

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

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

　　letcontent = listItemView.text.trimming（.whitespaceAndNewlines）

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

　　所以 Swift 3.0 才會(huì)將這個(gè)問題提上日程，并在這個(gè)版本中準(zhǔn)備解決這個(gè)問題。

　　規(guī)則

　　解決這個(gè)問題，肯定不能手動(dòng)的替換。因?yàn)橄到y(tǒng)庫的方法實(shí)在太多了，所以就需要總結(jié)出一系列替換規(guī)則。根據(jù)這些規(guī)則將相應(yīng)的標(biāo)識(shí)替換完成。

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

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

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

　　添加默認(rèn)參數(shù)- 對(duì)于 Objc 需要默認(rèn)參數(shù)的地方，會(huì)在 Swift 中添加上默認(rèn)參數(shù)，比如一些選項(xiàng)參數(shù)：

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

　　這個(gè) option 參數(shù)就會(huì)提供默認(rèn)參數(shù)。

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

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

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

　　下面是一個(gè)官方文檔中給出的轉(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 對(duì) Objc 依賴庫中的優(yōu)化了，這次優(yōu)化后，我們以后在用 Swift 來開發(fā) iOS App 的時(shí)候，就不會(huì)再混合兩種代碼風(fēng)格啦。