文章總結翻譯自：Seven Swift Snares & How to Avoid Them

Swift正在完成一個驚人的壯舉，它正在改變我們在蘋果設備上編程的方式，引入了很多現代范例，例如：函數式編程和相比于OC這種純面向對象語言更豐富的類型檢查。

Swift語言希望通過采用安全的編程模式去幫助開發者避免bug。然而這也會不可避免的產生一些人造的陷阱，他們會在編譯器不報錯的情況下引入一些Bug。這些陷阱有的已經在Swift book中提到，有一些還沒有。這里有七個我在去年遇到的陷阱，它們涉及Swift協議擴展、可選鏈和函數式編程。

協議擴展：強大但是需要謹慎使用

一個Swift類可以去繼承另一個類，這種能力是強大的。繼承將使類之間的特定關系更加清晰，并且支持細粒度代碼分享。但是，Swift中如果不是引用類型的話（如：結構體、枚舉），就不能具有繼承關系。然而，一個值類型可以繼承協議，同時協議可以繼承另一個協議。雖然協議除了類型信息外不能包含其他代碼，但是協議擴展（protocol extension）可以包含代碼。照這種方式，我們可以用繼承樹來實現代碼的分享共用，樹的葉子是值類型（結構體或枚舉類），樹的內部和根是協議和與他們對應的擴展。

但是Swift協議擴展的實現依然是一片新的、未開發的領域，尚存在一些問題。代碼并不總是按照我們期望的那樣執行。因為這些問題出現在值類型（結構體與枚舉）與協議組合使用的場景下，我們將使用類與協議組合使用的例子去說明這種場景下不存在陷阱。當我們重新改為使用值類型和協議的時候將會發生令人驚奇的事。

開始介紹我們的例子：classy pizza

假設這里有使用兩種不同谷物制作的三種Pizza：

enum Grain  { case Wheat, Corn }

class  NewYorkPizza  { let crustGrain: Grain = .Wheat }
class  ChicagoPizza  { let crustGrain: Grain = .Wheat }
class CornmealPizza  { let crustGrain: Grain = .Corn  }

我們可以通過crustGrain屬性取得披薩所對應的原料

NewYorkPizza().crustGrain   // returns Wheat
ChicagoPizza().crustGrain   // returns Wheat
CornmealPizza().crustGrain  // returns Corn

因為大多數的Pizza是用小麥(wheat)做的，這些公共代碼可以放進一個超類中作為默認執行的代碼。

enum Grain { case Wheat, Corn }

class Pizza {
    var crustGrain: Grain { return .Wheat }
    // other common pizza behavior
}
class NewYorkPizza: Pizza {}
class ChicagoPizza: Pizza {}

這些默認的代碼可以被重載去處理其它的情況（用玉米制作）

class CornmealPizza: Pizza {
    override var crustGain: Grain { return .Corn }
}

哎呀！這代碼是錯的，并且很幸運的是編譯器發現了這些錯誤。你能發現這個錯誤么？我們在第二個crustGain中少寫了r。Swift通過顯式的標注override避免這種錯誤。比如在這個例子中，我們用到了override，但是拼寫錯誤的"crustGain"其實并沒有重寫任何屬性，下面是修改后的代碼：

class CornmealPizza: Pizza {
     override var crustGrain: Grain { return .Corn }
}

現在它可以通過編譯并成功運行：

NewYorkPizza().crustGrain       // returns Wheat
ChicagoPizza().crustGrain       // returns Wheat
CornmealPizza().crustGrain      // returns Corn

同時Pizza超類允許我們的代碼在不知道Pizza具體類型的時候去操作pizzas。我們可以聲明一個Pizza類型的變量。

var pie: Pizza

但是通用類型Pizza仍然可以去得到特定類型的信息。

pie =  NewYorkPizza();      pie.crustGrain   // returns Wheat
pie =  ChicagoPizza();      pie.crustGrain   // returns Wheat
pie = CornmealPizza();      pie.crustGrain   // returns Corn

Swift的引用類型在這個Demo中工作的很好。但是如果這個程序涉及到并發性、競爭條件，我們可以使用值類型來避免這些。讓我們來試一下值類型的Pizza吧！

這里和上面一樣簡單，只需要把class修改為struct即可：

enum Grain { case Wheat, Corn }

struct  NewYorkPizza    { let crustGrain: Grain = .Wheat }
struct  ChicagoPizza    { let crustGrain: Grain = .Wheat }
struct CornmealPizza    { let crustGrain: Grain = .Corn  }

執行

NewYorkPizza()  .crustGrain     // returns Wheat
ChicagoPizza()  .crustGrain     // returns Wheat
CornmealPizza() .crustGrain     // returns Corn

當我們使用引用類型的時候，我們通過一個超類Pizza來達到目的。但是對于值類型將要求一個協議和一個協議擴展來合作完成。

protocol Pizza {}

extension Pizza {  var crustGrain: Grain { return .Wheat }  }

struct  NewYorkPizza: Pizza { }
struct  ChicagoPizza: Pizza { }
struct CornmealPizza: Pizza {  let crustGain: Grain = .Corn }

這段代碼可以通過編譯，我們來測試一下：

NewYorkPizza().crustGrain       // returns Wheat
 ChicagoPizza().crustGrain      // returns Wheat
CornmealPizza().crustGrain      // returns Wheat  What?!

對于執行結果，我們想說cornmeal pizza并不是Wheat制作的，返回結果出現錯誤！哎呀！我把
struct CornmealPizza: Pizza { let crustGain: Grain = .Corn }
中的 crustGrain寫成了crustGain，再一次忘記了r，但是對于值類型這里沒有override關鍵字去幫助編譯器去發現我們的錯誤。沒有編譯器的幫助，我們不得不更加小心的編寫代碼。

?? 在協議擴展中重寫協議中的屬性時要仔細核對

ok，我們把這個拼寫錯誤改正過來：

struct CornmealPizza: Pizza {  let crustGrain: Grain = .Corn }

重新執行

 NewYorkPizza().crustGrain      // returns Wheat
 ChicagoPizza().crustGrain      // returns Wheat
 CornmealPizza().crustGrain     // returns Corn  Hooray!    

為了在討論Pizza的時候不需要擔心到底是New York, Chicago, 還是 cornmeal，我們可以使用Pizza協議作為變量的類型。

var pie: Pizza

這個變量能夠在不同種類的Pizza中去使用

pie =  NewYorkPizza(); pie.crustGrain  // returns Wheat
pie =  ChicagoPizza(); pie.crustGrain  // returns Wheat
pie = CornmealPizza(); pie.crustGrain  // returns Wheat    Not again?!

為什么這個程序顯示cornmeal pizza 包含wheat？Swift編譯代碼的時候忽略了變量的目前實際值。代碼只能夠使用編譯時期的知道的信息，并不知道運行時期的具體信息。程序中可以在編譯時期得到的信息是pie是pizza類型，pizza協議擴展返回wheat，所以在結構體CornmealPizza中的重寫起不到任何作用。雖然編譯器本能夠在使用靜態調度替換動態調度時，為潛在的錯誤提出警告，但它實際上并沒有這么做。這里的粗心將帶來巨大的陷阱。

在這種情況下，Swift提供一種解決方案，除了在協議擴展中（extension）定義crustGrain屬性之外，還可以在協議中聲明。

protocol  Pizza {  var crustGrain: Grain { get }  }
extension Pizza {  var crustGrain: Grain { return .Wheat }  }

在協議內聲明變量并在協議拓展中定義，這樣會告訴編譯器關注變量pie運行時的值。

在協議中一個屬性的聲明有兩種不同的含義，靜態還是動態調度，取決于是否這個屬性在協議擴展中定義。

補充了協議中變量的聲明后，代碼可以正常運行了：

pie =  NewYorkPizza();  pie.crustGrain   // returns Wheat
pie =  ChicagoPizza();  pie.crustGrain   // returns Wheat
pie = CornmealPizza();  pie.crustGrain   // returns Corn    Whew!

?? 在協議擴展中定義的每一個屬性，需要在協議中進行聲明

然而這個設法避免陷阱的方式并不總是有效的。

導入的協議不能夠完全擴展。

框架（庫）可以使一個程序導入接口去使用，而不必包含相關實現。例如蘋果提供給我們提供了需要框架，實現了用戶體驗、系統設施和其他功能。Swift的擴展允許程序向導入的類、結構體、枚舉和協議中添加自己的屬性(這里的屬性并不是存儲屬性)。通過協議拓展添加的屬性，就好像它原來就在協議中一樣。但實際上定義在協議拓展中的屬性并非一等公民，因為通過協議拓展無法添加屬性的聲明。

我們首先實現一個框架，這個框架定義了Pizza協議和具體的類型

// PizzaFramework:

public protocol Pizza { }

public struct  NewYorkPizza: Pizza  { public init() {} }
public struct  ChicagoPizza: Pizza  { public init() {} }
public struct CornmealPizza: Pizza  { public init() {} }

導入框架并且擴展Pizza

import PizzaFramework

public enum Grain { case Wheat, Corn }

extension Pizza         { var crustGrain: Grain { return .Wheat } }
extension CornmealPizza { var crustGrain: Grain { return .Corn  } }

和以前一樣，靜態調度產生一個錯誤的答案

var pie: Pizza = CornmealPizza()
pie.crustGrain                            // returns Wheat   Wrong!

這個是因為（與剛才的解釋一樣）這個crustGrain屬性并沒有在協議中聲明，而是只是在擴展中定義。然而，我們沒有辦法對框架的代碼進行修改，因此也就不能解決這個問題。因此，想要通過擴展增加其他框架的協議屬性是不安全的。

?? 不要對導入的協議進行擴展，新增可能需要動態調度的屬性

正像剛才描述的那樣，框架與協議擴展之間的交互，限制了協議擴展的效用，但是框架并不是唯一的限制因素，同樣，類型約束也不利于協議擴展。

Attributes in restricted protocol extensions: declaration is no longer enough

回顧一下此前Pizza的例子：

enum Grain { case Wheat, Corn }

protocol  Pizza { var crustGrain: Grain { get }  }
extension Pizza { var crustGrain: Grain { return .Wheat }  }

struct  NewYorkPizza: Pizza  { }
struct  ChicagoPizza: Pizza  { }
struct CornmealPizza: Pizza  { let crustGrain: Grain = .Corn }

讓我們用Pizza做一頓飯。不幸的是，并不是每頓飯都會吃pizza，所以我們使用一個通用的Meal結構體來適應各種情況。我們只需要傳入一個參數就可以確定進餐的具體類型。

struct Meal: MealProtocol {
    let mainDish: MainDishOfMeal
}

結構體Meal繼承自MealProtocol協議，它可以測試meal是否包含谷蛋白。

protocol MealProtocol {
    typealias MainDish_OfMealProtocol
    var mainDish: MainDish_OfMealProtocol {get}
    var isGlutenFree: Bool {get}
}

為了避免中毒，代碼中使用了默認值（不含有谷蛋白）

extension MealProtocol {
    var isGlutenFree: Bool  { return false }
}

Swift中的 Where提供了一種方式去表達約束性協議擴展。當主菜是pizza的時候，我們知道pizza有scrustGrain屬性，我們就可以訪問這個屬性。如果沒where這里的限制，我們在不是Pizza的情況下訪問scrustGrain是不安全的。

extension MealProtocol  where  MainDish_OfMealProtocol: Pizza {
    var isGlutenFree: Bool  { return mainDish.crustGrain == .Corn }
}

一個帶有Where的擴展叫做約束性擴展。

讓我們做一份美味的cornmeal Pizza

let meal: Meal = Meal(mainDish: CornmealPizza())

結果：

meal.isGlutenFree   // returns false
// 根據協議拓展，理論上應該返回true   

正像我們在前面小節演示的那樣，當發生動態調度的時候，我們應該在協議中聲明，并且在協議擴展中進行定義。但是約束性擴展的定義總是靜態調度的。為了防止由于意外的靜態調度而引起的bug：

?? 如果一個新的屬性需要動態調度，避免使用約束性協議擴展

使用可選鏈賦值和副作用

Swift可以通過靜態地檢查變量是否為nil來避免錯誤，并使用一種方便的縮略表達式，可選鏈，用于忽略可能出現的nil。這一點也正是Objective-C的默認行為。

不幸的是，如果可選鏈中被賦值的引用有可能為空，就可能導致錯誤，考慮下面這段代碼，Holder中存放一個整數：

class Holder  {
    var x = 0
}

var n = 1
var h: Holder? = nil
h?.x = n++

在這段代碼的最后一行中，我們把n++賦值給h的屬性。除了賦值以外，變量n還會自增，我們稱此為副作用。

變量n最終的值會取決于h是否為nil。如果h不為nil，那么賦值語句執行，n++也會執行。但如果h為nil，不僅賦值語句不會執行，n++也不會執行。為了避免沒有發生副作用導致的令人驚訝的結果，我們應該：

?? 避免把一個有副作用的表達式的結果通過可選鏈賦值給等號左邊的變量

函數編程陷阱

由于Swift的支持，函數式編程的優點得以被帶入蘋果的生態圈中。Swift中的函數和閉包都是一等公民，不僅方便易用而且功能強大。不幸的是，其中也有一些我們需要小心避免的陷阱。

比如，inout參數會在閉包中默默的失效。

Swift的inout參數允許函數接受一個參數并直接對參數賦值，Swift的閉包支持在執行過程中引用被捕獲的函數。這些特性有助于我們寫出優雅易讀的代碼，所以你也許會把它們結合起來使用，但這種結合有可能會導致問題。

我們重寫crustGrain屬性來說明inout參數的使用，為簡單起見，開始時先不使用閉包：

enum Grain {
    case Wheat, Corn
}

struct CornmealPizza {
    func setCrustGrain(inout grain: Grain)  {
        grain = .Corn
    }
}

為了測試這個函數，我們給它傳一個變量作為參數。函數返回后，這個變量的值應該從Wheat變成了Corn：

let pizza = CornmealPizza()
var grain: Grain = .Wheat
pizza.setCrustGrain(&grain)
grain       // returns Corn

現在我們嘗試在函數中返回閉包，然后在閉包中設置參數的值：

struct CornmealPizza {
    func getCrustGrainSetter() -> (inout grain: Grain) -> Void {
        return { (inout grain: Grain) in
            grain = .Corn
        }
    }
}

使用這個閉包只需要多一次調用：

var grain: Grain = .Wheat
let pizza = CornmealPizza()
let aClosure = pizza.getCrustGrainSetter()
grain           // returns Wheat (We have not run the closure yet)
aClosure(grain: &grain)
grain           // returns Corn

到目前為止一切正常，但如果我們直接把參數傳進getCrustGrainSetter函數而不是閉包呢？

struct CornmealPizza {
    func getCrustGrainSetter(inout grain: Grain)  ->  () -> Void {
        return { grain = .Corn }
    }
}

然后再試一次：

var grain: Grain = .Wheat
let pizza = CornmealPizza()
let aClosure = pizza.getCrustGrainSetter(&grain)
print(grain)                // returns Wheat (We have not run the closure yet)
aClosure()
print(grain)                // returns Wheat  What?!?

inout參數在傳入閉包的作用域外時會失效，所以：

?? 避免在閉包中使用inout參數

這個問題在Swift文檔中提到過，但還有一個與之相關的問題值得注意，這與創建的閉包的等價方法：柯里化有關。

在使用柯里化技術時，inout參數顯得前后矛盾。

在一個創建并返回閉包的函數中，Swift為函數的類型和主體提供了一種簡潔的語法。盡管這種柯里化看上去僅是一種縮略表達式，但它與inout參數結合使用時卻會給人們帶來一些驚訝。為了說明這一點，我們用柯里化語法實現上面那個例子。函數沒有聲明為返回一個閉包，而是在第一個參數列表后加上了第二個參數列表，然后在函數體內省略了顯式的閉包創建：

struct CornmealPizza {
    func getCrustGrainSetterWithCurry(inout grain: Grain)() -> Void {
        grain = .Corn
    }
}

和顯式創建閉包時一樣，我們調用這個函數然后返回一個閉包：

var grain: Grain = .Wheat
let pizza = CornmealPizza()
let aClosure = pizza.getCrustGrainSetterWithCurry(&grain)

在上面的例子中，閉包被顯式創建但沒能成功為inout參數賦值，但這次就成功了：

aClosure()
grain               // returns Corn

這說明在柯里化函數中，inout參數可以正常使用，但是顯式的創建閉包時就不行了。

?? 避免在柯里化函數中使用inout參數，因為如果你后來將柯里化改為顯式的創建閉包，這段代碼就會產生錯誤

總結：七個避免

• 在協議擴展中重寫協議中的屬性時要仔細核對
• 在協議擴展中定義的每一個屬性，需要在協議中進行聲明
• 不要對導入的第三方協議進行屬性擴展，那樣可能需要動態調度
• 如果一個新的屬性需要動態調度，避免使用約束性協議擴展
• 避免把一個有副作用的表達式的結果通過可選鏈賦值給等號左邊的變量
• 避免在閉包中使用inout參數
• 避免在柯里化函數中使用inout參數，因為如果你后來將柯里化改為顯式的創建閉包，這段代碼就會產生錯誤