2.3.1 橫切關(guān)注點

我們再來看一個例子。這次讓我們遠(yuǎn)離動物世界，回到 Cocoa，假設(shè)我們有一個 ViewController，它繼承自 UIViewController，我們向其中添加一個 myMethod：

class ViewCotroller: UIViewController 
{ 
    // 繼承 
    // view, isFirstResponder()... 
     
    // 新加 
    func myMethod() { 
         
    } 
} 

如果這時候我們又有一個繼承自 UITableViewController 的 AnotherViewController，我們也想向其中添加同樣的 myMethod：

class AnotherViewController: UITableViewController 
{ 
    // 繼承 
    // tableView, isFirstResponder()... 
     
    // 新加 
    func myMethod() { 
         
    } 
} 

這時，我們迎來了 OOP 的第一個大困境，那就是我們很難在不同繼承關(guān)系的類里共用代碼。這里的問題用“行話”來說叫做“橫切關(guān)注點” (Cross-Cutting Concerns)。我們的關(guān)注點 myMethod 位于兩條繼承鏈 (UIViewController -> ViewCotroller 和 UIViewController -> UITableViewController -> AnotherViewController) 的橫切面上。

面向?qū)ο笫且环N不錯的抽象方式，但是肯定不是最好的方式。它無法描述兩個不同事物具有某個相同特性這一點。在這里，特性的組合要比繼承更貼切事物的本質(zhì)。

想要解決這個問題，我們有幾個方案：

• Copy & Paste

這是一個比較糟糕的解決方案，但是演講現(xiàn)場還是有不少朋友選擇了這個方案，特別是在工期很緊，無暇優(yōu)化的情況下。這誠然可以理解，但是這也是壞代碼的開頭。我們應(yīng)該盡量避免這種做法。

• 引入 BaseViewController

在一個繼承自 UIViewController 的 BaseViewController 上添加需要共享的代碼，或者干脆在 UIViewController 上添加 extension?？雌饋磉@是一個稍微靠譜的做法，但是如果不斷這么做，會讓所謂的 Base 很快變成垃圾堆。職責(zé)不明確，任何東西都能扔進(jìn) Base，你完全不知道哪些類走了 Base，而這個“超級類”對代碼的影響也會不可預(yù)估。

• 依賴注入

通過外界傳入一個帶有 myMethod 的對象，用新的類型來提供這個功能。這是一個稍好的方式，但是引入額外的依賴關(guān)系，可能也是我們不太愿意看到的。

• 多繼承

當(dāng)然，Swift 是不支持多繼承的。不過如果有多繼承的話，我們確實可以從多個父類進(jìn)行繼承，并將 myMethod 添加到合適的地方。有一些語言選擇了支持多繼承 (比如 C++)，但是它會帶來 OOP 中另一個著名的問題：菱形缺陷。

2.3.2 菱形缺陷

上面的例子中，如果我們有多繼承，那么 ViewController 和 AnotherViewController 的關(guān)系可能會是這樣的：

此處有圖片

在上面這種拓?fù)浣Y(jié)構(gòu)中，我們只需要在 ViewController 中實現(xiàn) myMethod，在 AnotherViewController 中也就可以繼承并使用它了?？雌饋砗芡昝?，我們避免了重復(fù)。

但是多繼承有一個無法回避的問題，就是兩個父類都實現(xiàn)了同樣的方法時，子類該怎么辦?我們很難確定應(yīng)該繼承哪一個父類的方法。因為多繼承的拓?fù)浣Y(jié)構(gòu)是一個菱形，所以這個問題又被叫做菱形缺陷 (Diamond Problem)。

像是 C++ 這樣的語言選擇粗暴地將菱形缺陷的問題交給程序員處理，這無疑非常復(fù)雜，并且增加了人為錯誤的可能性。而絕大多數(shù)現(xiàn)代語言對多繼承這個特性選擇避而遠(yuǎn)之。

2.3.3 動態(tài)派發(fā)安全性

Objective-C 恰如其名，是一門典型的 OOP 語言，同時它繼承了 Small Talk 的消息發(fā)送機(jī)制。這套機(jī)制十分靈活，是 OC 的基礎(chǔ)思想，但是有時候相對危險?？紤]下面的代碼：

ViewController *v1 = ... 
[v1 myMethod]; 
 
AnotherViewController *v2 = ... 
[v2 myMethod]; 
 
NSArray *array = @[v1, v2]; 
for (id obj in array) { 
    [obj myMethod]; 
} 

我們?nèi)绻?ViewController 和 AnotherViewController 中都實現(xiàn)了 myMethod 的話，這段代碼是沒有問題的。myMethod 將會被動態(tài)發(fā)送給 array 中的 v1 和 v2。但是，要是我們有一個沒有實現(xiàn) myMethod 的類型，會如何呢?

NSObject *v3 = [NSObject new] 
// v3 沒有實現(xiàn) `myMethod` 
 
NSArray *array = @[v1, v2, v3]; 
for (id obj in array) { 
    [obj myMethod]; 
} 
 
// Runtime error: 
// unrecognized selector sent to instance blabla 

編譯依然可以通過，但是顯然，程序?qū)⒃谶\行時崩潰。Objective-C 是不安全的，編譯器默認(rèn)你知道某個方法確實有實現(xiàn)，這是消息發(fā)送的靈活性所必須付出的代價。

而在 app 開發(fā)看來，用可能的崩潰來換取靈活性，顯然這個代價太大了。雖然這不是 OOP 范式的問題，但它確實在 Objective-C 時代給我們帶來了切膚之痛。

2.3.4 三大困境

我們可以總結(jié)一下 OOP 面臨的這幾個問題:

• 動態(tài)派發(fā)安全性
• 橫切關(guān)注點
• 菱形缺陷

首先，在 OC 中動態(tài)派發(fā)讓我們承擔(dān)了在運行時才發(fā)現(xiàn)錯誤的風(fēng)險，這很有可能是發(fā)生在上線產(chǎn)品中的錯誤。其次，橫切關(guān)注點讓我們難以對對象進(jìn)行完美的建模，代碼的重用也會更加糟糕。

3. 協(xié)議擴(kuò)展和面向協(xié)議編程

3.1 使用協(xié)議解決 OOP 困境

協(xié)議并不是什么新東西，也不是 Swift 的發(fā)明。在 Java 和 C# 里，它叫做 Interface。而 Swift 中的 protocol 將這個概念繼承了下來，并發(fā)揚(yáng)光大。讓我們回到一開始定義的那個簡單協(xié)議，并嘗試著實現(xiàn)這個協(xié)議：

protocol Greetable { 
    var name: String { get } 
    func greet() 
} 

struct Person: Greetable { 
    let name: String 
    func greet() { 
        print("你好 \(name)") 
    } 
} 
Person(name: "Wei Wang").greet() 

實現(xiàn)很簡單，Person 結(jié)構(gòu)體通過實現(xiàn) name 和 greet 來滿足 Greetable。在調(diào)用時，我們就可以使用 Greetable 中定義的方法了。

3.1.1 動態(tài)派發(fā)安全性

除了 Person，其他類型也可以實現(xiàn) Greetable，比如 Cat：

struct Cat: Greetable { 
    let name: String 
    func greet() { 
        print("meow~ \(name)") 
    } 
} 

現(xiàn)在，我們就可以將協(xié)議作為標(biāo)準(zhǔn)類型，來對方法調(diào)用進(jìn)行動態(tài)派發(fā)了：

let array: [Greetable] = [ 
  Person(name: "Wei Wang"),  
  Cat(name: "onevcat")] 
for obj in array { 
 obj.greet() 
} 
// 你好 Wei Wang 
// meow~ onevcat 

對于沒有實現(xiàn) Greetbale 的類型，編譯器將返回錯誤，因此不存在消息誤發(fā)送的情況：

struct Bug: Greetable { 
    let name: String 
} 
 
// Compiler Error:  
// 'Bug' does not conform to protocol 'Greetable' 
// protocol requires function 'greet()' 

這樣一來，動態(tài)派發(fā)安全性的問題迎刃而解。如果你保持在 Swift 的世界里，那這個你的所有代碼都是安全的。

• 動態(tài)派發(fā)安全性
• 橫切關(guān)注點
• 菱形缺陷

3.1.2 橫切關(guān)注點

使用協(xié)議和協(xié)議擴(kuò)展，我們可以很好地共享代碼?；氐缴弦还?jié)的 myMethod 方法，我們來看看如何使用協(xié)議來搞定它。首先，我們可以定義一個含有 myMethod 的協(xié)議：

protocol P { 
    func myMethod() 
} 

注意這個協(xié)議沒有提供任何的實現(xiàn)。我們依然需要在實際類型遵守這個協(xié)議的時候為它提供具體的實現(xiàn)：

// class ViewController: UIViewController 
extension ViewController: P { 
    func myMethod() { 
        doWork() 
    } 
} 
 
// class AnotherViewController: UITableViewController 
extension AnotherViewController: P { 
    func myMethod() { 
        doWork() 
    } 
} 

你可能不禁要問，這和 Copy & Paste 的解決方式有何不同?沒錯，答案就是 – 沒有不同。不過稍安勿躁，我們還有其他科技可以解決這個問題，那就是協(xié)議擴(kuò)展。協(xié)議本身并不是很強(qiáng)大，只是靜態(tài)類型語言的編譯器保證，在很多靜態(tài)語言中也有類似的概念。

那到底是什么讓 Swift 成為了一門協(xié)議優(yōu)先的語言?真正使協(xié)議發(fā)生質(zhì)變，并讓大家如此關(guān)注的原因，其實是在 WWDC 2015 和 Swift 2 發(fā)布時，Apple 為協(xié)議引入了一個新特性，協(xié)議擴(kuò)展，它為 Swift 語言帶來了一次革命性的變化。

所謂協(xié)議擴(kuò)展，就是我們可以為一個協(xié)議提供默認(rèn)的實現(xiàn)。對于 P，可以在 extension P 中為 myMethod 添加一個實現(xiàn)：

protocol P { 
    func myMethod() 
} 
 
extension P { 
    func myMethod() { 
        doWork() 
    } 
} 

有了這個協(xié)議擴(kuò)展后，我們只需要簡單地聲明 ViewController 和 AnotherViewController 遵守 P，就可以直接使用 myMethod 的實現(xiàn)了：

extension ViewController: P { } 
extension AnotherViewController: P { } 
 
viewController.myMethod() 
anotherViewController.myMethod() 

不僅如此，除了已經(jīng)定義過的方法，我們甚至可以在擴(kuò)展中添加協(xié)議里沒有定義過的方法。在這些額外的方法中，我們可以依賴協(xié)議定義過的方法進(jìn)行操作。我們之后會看到更多的例子?？偨Y(jié)下來：

• 協(xié)議定義
  • 提供實現(xiàn)的入口
  • 遵循協(xié)議的類型需要對其進(jìn)行實現(xiàn)
• 協(xié)議擴(kuò)展
  • 為入口提供默認(rèn)實現(xiàn)
  • 根據(jù)入口提供額外實現(xiàn)

這樣一來，橫切點關(guān)注的問題也簡單安全地得到了解決。

• 動態(tài)派發(fā)安全性
• 橫切關(guān)注點
• 菱形缺陷

3.1.3 菱形缺陷

最后我們看看多繼承。多繼承中存在的一個重要問題是菱形缺陷，也就是子類無法確定使用哪個父類的方法。在協(xié)議的對應(yīng)方面，這個問題雖然依然存在，但卻是可以唯一安全地確定的。我們來看一個多個協(xié)議中出現(xiàn)同名元素的例子：

protocol Nameable { 
    var name: String { get } 
} 
 
protocol Identifiable { 
    var name: String { get } 
    var id: Int { get } 
} 

如果有一個類型，需要同時實現(xiàn)兩個協(xié)議的話，它必須提供一個 name 屬性，來同時滿足兩個協(xié)議的要求：

struct Person: Nameable, Identifiable { 
    let name: String  
    let id: Int 
} 
 
// `name` 屬性同時滿足 Nameable 和 Identifiable 的 name 

這里比較有意思，又有點讓人困惑的是，如果我們?yōu)槠渲械哪硞€協(xié)議進(jìn)行了擴(kuò)展，在其中提供了默認(rèn)的 name 實現(xiàn)，會如何?？紤]下面的代碼：

extension Nameable { 
    var name: String { return "default name" } 
} 
 
struct Person: Nameable, Identifiable { 
    // let name: String  
    let id: Int 
} 
 
// Identifiable 也將使用 Nameable extension 中的 name 

這樣的編譯是可以通過的，雖然 Person 中沒有定義 name，但是通過 Nameable 的 name (因為它是靜態(tài)派發(fā)的)，Person 依然可以遵守 Identifiable。不過，當(dāng) Nameable 和 Identifiable 都有 name的協(xié)議擴(kuò)展的話，就無法編譯了：

extension Nameable { 
    var name: String { return "default name" } 
} 
 
extension Identifiable { 
    var name: String { return "another default name" } 
} 
 
struct Person: Nameable, Identifiable { 
    // let name: String  
    let id: Int 
} 
 
// 無法編譯，name 屬性沖突 

這種情況下，Person 無法確定要使用哪個協(xié)議擴(kuò)展中 name 的定義。在同時實現(xiàn)兩個含有同名元素的協(xié)議，并且它們都提供了默認(rèn)擴(kuò)展時，我們需要在具體的類型中明確地提供實現(xiàn)。這里我們將 Person 中的 name 進(jìn)行實現(xiàn)就可以了：

extension Nameable { 
    var name: String { return "default name" } 
} 
 
extension Identifiable { 
    var name: String { return "another default name" } 
} 
 
struct Person: Nameable, Identifiable { 
    let name: String  
    let id: Int 
} 
 
Person(name: "onevcat", id: 123).name // onevcat 

這里的行為看起來和菱形問題很像，但是有一些本質(zhì)不同。首先，這個問題出現(xiàn)的前提條件是同名元素以及同時提供了實現(xiàn)，而協(xié)議擴(kuò)展對于協(xié)議本身來說并不是必須的。

其次，我們在具體類型中提供的實現(xiàn)一定是安全和確定的。當(dāng)然，菱形缺陷沒有被完全解決，Swift 還不能很好地處理多個協(xié)議的沖突，這是 Swift 現(xiàn)在的不足。

• 動態(tài)派發(fā)安全性
•  橫切關(guān)注點
• 菱形缺陷

作者：王巍(onevcat)，江湖人稱 "喵神"，他是 ObjC 中國組織的發(fā)起人和領(lǐng)導(dǎo)者，也是著名開源框架 Kingfisher 的作者。