[[403413]]

本文轉載自微信公眾號「Swift 社區」，作者Onevcat。轉載本文請聯系Swift 社區公眾號。

本文筆者在 MDCC 16 (移動開發者大會) 上 iOS 專場中的主題演講的文字整理。發布于 2016年11月29日 最后更新于 2020年10月22日

您可以在這里[1]找到演講使用的 Keynote，部分示例代碼可以在 MDCC 2016 的 官方 repo[2]中找到。因為全部內容比較長，所以分成了上下兩個部分，本文 (上) 主要介紹了一些理論方面的內容，包括面向對象編程存在的問題，面向協議的基本概念和決策模型等，下半部分主要展示了一些筆者日常使用面向協議思想和 Cocoa 開發結合的示例代碼，并對其進行了一些解說。

1. 引子

面向協議編程 (Protocol Oriented Programming，以下簡稱 POP) 是 Apple 在 2015 年 WWDC 上提出的 Swift 的一種編程范式。相比與傳統的面向對象編程 (OOP)，POP 顯得更加靈活。結合 Swift 的值語義特性和 Swift 標準庫的實現，這一年來大家發現了很多 POP 的應用場景。

本次演講希望能在介紹 POP 思想的基礎上，引入一些日常開發中可以使用 POP 的場景，讓與會來賓能夠開始在日常工作中嘗試 POP，并改善代碼設計。

2. 什么是 Swift 協議

2.1 Protocol

Swift 標準庫中有 50 多個復雜不一的協議，幾乎所有的實際類型都是滿足若干協議的。protocol 是 Swift 語言的底座，語言的其他部分正是在這個底座上組織和建立起來的。這和我們熟知的面向對象的構建方式很不一樣。

一個最簡單但是有實際用處的 Swift 協議定義如下：

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

這幾行代碼定義了一個名為 Greetable 的協議，其中有一個 name 屬性的定義，以及一個 greet 方法的定義。

所謂協議，就是一組屬性和/或方法的定義，而如果某個具體類型想要遵守一個協議，那它需要實現這個協議所定義的所有這些內容。協議實際上做的事情不過是“關于實現的約定”。

2.2 面向對象

在深入 Swift 協議的概念之前，我想先重新讓大家回顧一下面向對象。相信我們不論在教科書或者是博客等各種地方對這個名詞都十分熟悉了。那么有一個很有意思，但是其實并不是每個程序員都想過的問題，面向對象的核心思想究竟是什么?

我們先來看一段面向對象的代碼：

class Animal { 
    var leg: Int { return 2 } 
    func eat() { 
        print("eat food.") 
    } 
    func run() { 
        print("run with \(leg) legs") 
    } 
} 
 
class Tiger: Animal { 
    override var leg: Int { return 4 } 
    override func eat() { 
        print("eat meat.") 
    } 
} 
 
let tiger = Tiger() 
tiger.eat() // "eat meat" 
tiger.run() // "run with 4 legs" 

父類 Animal 定義了動物的 leg (這里應該使用虛類，但是 Swift 中沒有這個概念，所以先請無視這里的 return 2)，以及動物的 eat 和 run 方法，并為它們提供了實現。子類的 Tiger 根據自身情況重寫了 leg (4 條腿)和 eat (吃肉)，而對于 run，父類的實現已經滿足需求，因此不必重寫。

我們看到 Tiger 和 Animal 共享了一部分代碼，這部分代碼被封裝到了父類中，而除了 Tiger 的其他的子類也能夠使用 Animal 的這些代碼。這其實就是 OOP 的核心思想 - 使用封裝和繼承，將一系列相關的內容放到一起。

我們的前輩們為了能夠對真實世界的對象進行建模，發展出了面向對象編程的概念，但是這套理念有一些缺陷。雖然我們努力用這套抽象和繼承的方法進行建模，但是實際的事物往往是一系列特質的組合，而不單單是以一脈相承并逐漸擴展的方式構建的。

所以最近大家越來越發現面向對象很多時候其實不能很好地對事物進行抽象，我們可能需要尋找另一種更好的方式。

2.3 面向對象編程的困境

2.3.1 橫切關注點

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

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

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

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

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

面向對象是一種不錯的抽象方式，但是肯定不是最好的方式。它無法描述兩個不同事物具有某個相同特性這一點。在這里，特性的組合要比繼承更貼切事物的本質。

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

• Copy & Paste

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

• 引入 BaseViewController

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

• 依賴注入

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

• 多繼承

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

2.3.2 菱形缺陷

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

此處有圖片

在上面這種拓撲結構中，我們只需要在 ViewController 中實現 myMethod，在 AnotherViewController 中也就可以繼承并使用它了。看起來很完美，我們避免了重復。

但是多繼承有一個無法回避的問題，就是兩個父類都實現了同樣的方法時，子類該怎么辦?我們很難確定應該繼承哪一個父類的方法。因為多繼承的拓撲結構是一個菱形，所以這個問題又被叫做菱形缺陷 (Diamond Problem)。

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

2.3.3 動態派發安全性

Objective-C 恰如其名，是一門典型的 OOP 語言，同時它繼承了 Small Talk 的消息發送機制。這套機制十分靈活，是 OC 的基礎思想，但是有時候相對危險。考慮下面的代碼：

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

我們如果在 ViewController 和 AnotherViewController 中都實現了 myMethod 的話，這段代碼是沒有問題的。myMethod 將會被動態發送給 array 中的 v1 和 v2。但是，要是我們有一個沒有實現 myMethod 的類型，會如何呢?

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

編譯依然可以通過，但是顯然，程序將在運行時崩潰。Objective-C 是不安全的，編譯器默認你知道某個方法確實有實現，這是消息發送的靈活性所必須付出的代價。

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

2.3.4 三大困境

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

• 動態派發安全性
• 橫切關注點
• 菱形缺陷

首先，在 OC 中動態派發讓我們承擔了在運行時才發現錯誤的風險，這很有可能是發生在上線產品中的錯誤。其次，橫切關注點讓我們難以對對象進行完美的建模，代碼的重用也會更加糟糕。

3. 協議擴展和面向協議編程

3.1 使用協議解決 OOP 困境

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

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

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

實現很簡單，Person 結構體通過實現 name 和 greet 來滿足 Greetable。在調用時，我們就可以使用 Greetable 中定義的方法了。

3.1.1 動態派發安全性

除了 Person，其他類型也可以實現 Greetable，比如 Cat：

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

現在，我們就可以將協議作為標準類型，來對方法調用進行動態派發了：

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

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

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

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

• 動態派發安全性
• 橫切關注點
• 菱形缺陷

3.1.2 橫切關注點

使用協議和協議擴展，我們可以很好地共享代碼。回到上一節的 myMethod 方法，我們來看看如何使用協議來搞定它。首先，我們可以定義一個含有 myMethod 的協議：

protocol P { 
    func myMethod() 
} 

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

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

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

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

所謂協議擴展，就是我們可以為一個協議提供默認的實現。對于 P，可以在 extension P 中為 myMethod 添加一個實現：

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

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

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

不僅如此，除了已經定義過的方法，我們甚至可以在擴展中添加協議里沒有定義過的方法。在這些額外的方法中，我們可以依賴協議定義過的方法進行操作。我們之后會看到更多的例子。總結下來：

• 協議定義
  • 提供實現的入口
  • 遵循協議的類型需要對其進行實現
• 協議擴展
  • 為入口提供默認實現
  • 根據入口提供額外實現

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

• 動態派發安全性
• 橫切關注點
• 菱形缺陷

3.1.3 菱形缺陷

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

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

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

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

這里比較有意思，又有點讓人困惑的是，如果我們為其中的某個協議進行了擴展，在其中提供了默認的 name 實現，會如何。考慮下面的代碼：

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 (因為它是靜態派發的)，Person 依然可以遵守 Identifiable。不過，當 Nameable 和 Identifiable 都有 name的協議擴展的話，就無法編譯了：

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 無法確定要使用哪個協議擴展中 name 的定義。在同時實現兩個含有同名元素的協議，并且它們都提供了默認擴展時，我們需要在具體的類型中明確地提供實現。這里我們將 Person 中的 name 進行實現就可以了：

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 

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

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

• 動態派發安全性
•  橫切關注點
• 菱形缺陷

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