Protocol Oriented Programming：POP 真的比 OOP (物件導向編程) 更好嗎？

Local reasoning 不適用於這些複雜的實體 (Entities)，有太多的面向和關係要考慮。

比較數值語義與引用語義

正如上一篇文章提到，蘋果正在推廣 POP 和數值語義的相關概念。上回教程已向讀者展示程式碼，今天我將再次示範，這應該使引用語義和數值語義的意義更明顯。請參考上回教程的 ObjectThatFlies 協定，與今天 List、FIFO、LIFO 和相關協定的實作程式碼。

蘋果工程師 Alex 認為，我們應該使用“數值類型和協定來讓你的 App 更好”，請參考這個 Playground 範例中名為 “Understanding Value Semantics” 的代碼文檔中所引述：

Sequences and collections in the standard library use value semantics, which makes it easy to reason about your code. Every variable has an independent value, and references to that value aren’t shared. For example, when you pass an array to a function, that function can’t accidentally modify the caller’s copy of the array.

當然，這適用於所有使用數值語義的類型，希望你下載並看一次整個 Playground 範例。

我不會、亦不能捨棄具有引用語義的類別，我自己有太多基於類別 (Class-based) 的程式碼，且用這數以百萬計的 Class-based 程式碼來服務我的客戶。我同意數值語義通常比引用語義更安全，當我撰寫的新程式碼或重構現有程式碼時，會基於不同個案考慮使用它。

引用語義可能因類別實例 (引用) 導致資料產生「無預期的影響」。 有人稱這為 “Unintended mutation (意外突變)”。我們可以參考此連結影片的一些技巧，來盡量減少引用語義的副作用，但我承認我越來越重視數值語義。

數值語義讓我們能避免對變量進行無預期的更改，這是一件非常好的事情。我們避免了因 Unintended mutation 而產生的副作用，因為「每個變量都有獨立的數值，並且對該數值的引用不會共享。」

由於 Swift struct 是一種數值類型，並且可以採用協定，加上 Apple 比起 OOP 更推薦使用 POP，所以你有理由支持「協定和數值面向編程 (Value Oriented Programming)」。

Local reasoning

讓我們來談談一個值得讚揚的目標，Apple 稱之為 “Local reasoning”。它是由蘋果工程師 Alex 在 WWDC 2016 – Session 419 “Protocol and Value Oriented Programming in UIKit Apps” 中所介紹的，這是蘋果推廣 POP 的第三個概念。

我認為這並不是新的概念，多年前，教授、同事、導師、開發者等都在談論這個技巧，例如：永不編寫長於一頁的程式碼，而且越短越好、拆分大型函式為多個小型函式、拆分大型程式碼檔案為多個小型程式碼檔案、使用有意義的變數名稱、在實作前花時間來設計架構、嚴謹且一致地使用空格及縮排、將相關連的屬性及行為分組到類別及結構中，並將相關的類別和/或結構整理到同一個組織單位中，如框架或函式庫。但它在蘋果解釋 POP 時被提出來了。

引述 Alex 的話：

Local reasoning means that when you look at the code, right in front of you, you don’t have to think about how the rest of your code interacts with that one function. You may have had this feeling before and that’s just a name for that feeling. For example, maybe when you just joined a new team and you have tons of code to look at but very little context, can you understand what’s going on in that single function? And so the ability to do that is really important because it makes it easier to maintain, easier to write, and easier to test, and easier to write the code the first time.

嗯⋯⋯ 這情境有沒有曾經發生在你身上？我閱讀過某些開發者寫得很好的程式碼，也寫過一些非常易讀的程式碼。但是說實話，在這行業 30 年後，大多數我所維護和/ 或優化的現有程式碼中，並沒有給我 Alex 描述的那種感覺。很多時候我非常沮喪，常常會看著一段程式碼而不知所云。

Swift 原始碼是公開的，請快速瀏覽一下下列函式，但不要太久時間試圖理解它：

public mutating func next() -> Any? {
    if index + 1 > count {
        index = 0
        // ensure NO ivars of self are actually captured
        let enumeratedObject = enumerable
        var localState = state
        var localObjects = objects
        
        (count, useObjectsBuffer) = withUnsafeMutablePointer(to: &localObjects) {
            let buffer = AutoreleasingUnsafeMutablePointer($0)
            return withUnsafeMutablePointer(to: &localState) { (statePtr: UnsafeMutablePointer) -> (Int, Bool) in
                let result = enumeratedObject.countByEnumerating(with: statePtr, objects: buffer, count: 16)
                if statePtr.pointee.itemsPtr == buffer {
                    // Most cocoa classes will emit their own inner pointer buffers instead of traversing this path. Notable exceptions include NSDictionary and NSSet
                    return (result, true)
                } else {
                    // this is the common case for things like NSArray
                    return (result, false)
                }
            }
        }
        
        state = localState // restore the state value
        objects = localObjects // copy the object pointers back to the self storage
        
        if count == 0 { return nil }
    }
        
    defer { index += 1 }
    
        if !useObjectsBuffer {
        return state.itemsPtr![index]
    } else {
        switch index {
        case 0: return objects.0!.takeUnretainedValue()
        case 1: return objects.1!.takeUnretainedValue()
        case 2: return objects.2!.takeUnretainedValue()
        case 3: return objects.3!.takeUnretainedValue()
        case 4: return objects.4!.takeUnretainedValue()
        case 5: return objects.5!.takeUnretainedValue()
        case 6: return objects.6!.takeUnretainedValue()
        case 7: return objects.7!.takeUnretainedValue()
        case 8: return objects.8!.takeUnretainedValue()
        case 9: return objects.9!.takeUnretainedValue()
        case 10: return objects.10!.takeUnretainedValue()
        case 11: return objects.11!.takeUnretainedValue()
        case 12: return objects.12!.takeUnretainedValue()
        case 13: return objects.13!.takeUnretainedValue()
        case 14: return objects.14!.takeUnretainedValue()
        case 15: return objects.15!.takeUnretainedValue()
        default: fatalError("Access beyond storage buffer")
        }
    }
}

老實說，你可以看一眼就明白這段程式碼嗎？我不可以。我不得不多閱讀幾次，並查找函數定義之類等。根據我的經驗，這樣的程式碼無處不在，而且通常是不可避免的。

現在讓我們考慮理解一個 Swift 類型 (當然，它不是一個函數)。看看 Swift 內 Array 的定義。我的天啊。它繼承自 11 個協定，包括 BidirectionalCollection、Collection、CustomDebugStringConvertible、CustomReflectable、CustomStringConvertible、ExpressibleByArrayLiteral、MutableCollection、RandomAccessCollection、RangeReplaceableCollection、和 Sequence。點擊 “VIEW PROTOCOL HIERARCHY – >” 連結按鈕，並看看這複雜的繼承關係圖。

最重要的是，如果你能夠開始一個新專案，並讓整個團隊自願購買同一套軟件開發最佳實踐指南，那麼實現 Local reasoning 就容易多了。如果一次重構少量的程式碼，則為實現 Local reasoning 提供了另一個機會。對於我來說，像其他事情一樣，重構需要小心謹慎地完成，並且要根據自身需求選擇最適合的方案。

請記住，你總會面對一些非常複雜的商業邏輯，當它們轉譯成程式碼時，團隊新成員將會需要接受某種形式的領域知識訓練和/或灌輸，才能夠流暢地閱讀你的程式碼，她/他很可能需要查找一些函數、類別、結構、列舉、變數等的定義。

委任 (Delegation) 與協定 (Protocols)

在整個 iOS 中，委託設計模式無處不在，而協定則扮演著很重要的角色。我們不再在這裡重新講述相關內容，讀者可以在此處閱讀我在 AppCoda 的相關教程。

協定類型 (Protocols as types) 和協定多態性 (Protocol Polymorphism)

本篇教程不會在這個主題上花太多時間，我已經說了很多關於協定的知識，並向你展示了很多範例代碼。這邊給讀者一項任務，我希望你研究使用 Swift 協定作為類型 (如委託) 的重要性，以及它們實現多態性 (例如：你建置一個擁有許多 struct 的工廠模型，它們都符合同個家族協定中的協定)，為我們提供了多大的靈活性。

協定類型
請記住，在我關於 Delegates 的文章中，我定義過這個屬性：

var delegate: LogoDownloaderDelegate?

在這裡，LogoDownloaderDelegate 是一個協定，然後我呼叫協定中的一個方法。

協定多態性

就像在 OOP 中一樣，藉由遵從同族的父協定 (Families’ Parent Protocol)，我們可以讓同族協定下的多種類型進行互動。以下的程式碼就是最佳範例：

protocol Top {
    var protocolName: String { get }
}

protocol Middle: Top {
    
}

protocol Bottom: Middle {
    
}

struct TopStruct : Top {
    var protocolName: String = "TopStruct"
}

struct MiddleStruct : Middle {
    var protocolName: String = "MiddleStruct"
}

struct BottomStruct : Bottom {
    var protocolName: String = "BottomStruct"
}

let top = TopStruct()
let middle = MiddleStruct()
let bottom = BottomStruct()

var topStruct: Top
topStruct = bottom
print("\(topStruct)\n")
// prints "BottomStruct(protocolName: "BottomStruct")"

topStruct = middle
print("\(topStruct)\n")
// prints "MiddleStruct(protocolName: "MiddleStruct")"

topStruct = top
print("\(topStruct)\n")
// prints "TopStruct(protocolName: "TopStruct")"

let protocolStructs:[Top] = [top,middle,bottom]

for protocolStruct in protocolStructs {
    print("\(protocolStruct)\n")
}

如果你在 Playground 運行這段程式碼，控制台將輸出下列訊息:

BottomStruct(protocolName: "BottomStruct")

MiddleStruct(protocolName: "MiddleStruct")

TopStruct(protocolName: "TopStruct")

TopStruct(protocolName: "TopStruct")

MiddleStruct(protocolName: "MiddleStruct")

BottomStruct(protocolName: "BottomStruct")

實際於 UIKit 應用協定

讓我們開始大膽嘗試編寫一些 Swift 4 代碼，用於建置 iOS 應用程式，希望這段程式碼能讓你透過協定構建和/ 或擴展程式碼的角度開始思考。我們稱之為 “Protocol-oriented programming” 或 POP，也是我在兩篇系列文章中一直持續探討的應用。

我選擇展示如何擴展或優化 UIKit 類別，因為 1) 你可能已經很習慣使用它們，而且 2) 要從自訂的類別中，擴展 iOS SDK 類別 (例如：UIView) 是更棘手的。

我在 Xcode 9 專案中以 Single View App 模板，編寫這些 UIView 優化 (Enhancement) 程式碼。

請注意，我正在使用 default 協定擴展來優化 UIView——要安全地執行這項操作，關鍵在於調用 “Conditional Conformance” (參考此處)。由於我只對擴展 UIView 類別感興趣，因此讓編譯器執行它，並將其設為必要條件。

我經常將 UIView 類別當成容器，來組織應用程式螢幕中的其他 UI 元素。有時候，我會以裝飾的方式使用這些容器視圖，以改善 UI 的外觀和佈局。

我將在下文創建三個協定，以定制 UIView 的外觀。這個 ani-GIF，展示了應用該三個協定的結果：

請注意，我在此遵循 “Local reasoning” 原則，每個基於協定 (Protocol-based) 的解決方案不超過一頁。我希望你可以看看每一個方案，它們包含的程式碼不太多，但仍然非常強大。

替 UIView 添加一個 Default border

假設我想要有很多 UIView 的實例，並全都具有相同的邊框 (Border)，就像在有顏色主題的 App 一樣。此類別的範例，就是上圖中綠色最頂的視圖。

protocol SimpleViewWithBorder {}

// SAFETY: Constrain "addBorder" only to UIViews.
extension SimpleViewWithBorder where Self : UIView {
    func addBorder() -> Void {
        layer.borderColor = UIColor.green.cgColor
        layer.borderWidth = 10.0
    }
}

class SimpleUIViewWithBorder : UIView, SimpleViewWithBorder {
}

為了創建、配置並顯示 SimpleUIViewWithBorder 的實例，我將以下程式碼放在 ViewController 子類的 IBAction 中：

...
    @IBAction func addViewButtonTapped(_ sender: Any) {
        let customFrame0 = CGRect(x: 110, y: 100, width: 100, height: 100)
        let customView0 = SimpleUIViewWithBorder(frame: customFrame0)
        customView0.addBorder()
        self.view.addSubview(customView0)
...

我不用為 UIView 這個子類，創建一個特定的初始化函式。

替 UIView 添加預設的背景顏色

假設我想要 UIView 的幾個實例都具有相同的背景顏色。此類別的範例，就是上圖中藍色置中的視圖。注意，我正在實現可配置的 UIView，你看到了嗎？

protocol ViewWithBackground {
    var customBackgroundColor: UIColor { get }
}

extension ViewWithBackground where Self : UIView {
    func addBackgroundColor() -> Void {
        backgroundColor = customBackgroundColor
    }
}

class UIViewWithBackground : UIView, ViewWithBackground {
    let customBackgroundColor: UIColor = .blue
}

為了創建、配置並顯示 UIViewWithBackground 的實例，我將以下程式碼放在 ViewController 子類的 IBAction 中：

...
        let customFrame1 = CGRect(x: 110, y: 210, width: 100, height: 100)
        let customView1 = UIViewWithBackground(frame: customFrame1)
        customView1.addBackgroundColor()
        self.view.addSubview(customView1)
...

我不用為 UIView 的這個子類創建一個特定的初始化函式。

替 UIView 添加可配置的邊框顏色

現在我希望能夠為 UIView 的多個實例，配置邊框的顏色和粗幼。通過以下實作，我可以創建任意數量的視圖，並根據需要使用不同的邊框顏色和粗幼。此類別的範例，就是上圖中紅色最底的視圖。在協定添加可配置的屬性需要付出一些代價，我要能夠初始化那些屬性，所以我替協定添加了一個 init，這意味著我必須能調用 UIView 初始化函式，你可以在下列程式碼中看到：

protocol ViewWithBorder {
    var borderColor: UIColor { get }
    var borderThickness: CGFloat { get }
    init(borderColor: UIColor, borderThickness: CGFloat, frame: CGRect)
}

extension ViewWithBorder where Self : UIView {
    func addBorder() -> Void {
        layer.borderColor = borderColor.cgColor
        layer.borderWidth = borderThickness
    }
}

class UIViewWithBorder : UIView, ViewWithBorder {
    let borderColor: UIColor
    let borderThickness: CGFloat
    
    // This initializer is required by UIView.
    required init(borderColor: UIColor, borderThickness: CGFloat, frame: CGRect) {
        self.borderColor = borderColor
        self.borderThickness = borderThickness
        super.init(frame: frame)
    }
    
    // This initializer is required by UIView.
    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

為了創建、配置並顯示 UIViewWithBorder 的實例，我將以下程式碼放在 ViewController 子類的 IBAction 中：

...
        let customFrame2 = CGRect(x: 110, y: 320, width: 100, height: 100)
        let customView2 = UIViewWithBorder(borderColor: .red, borderThickness: 10.0, frame: customFrame2)
        customView2.addBorder()
        self.view.addSubview(customView2)
...

我不想做的事

我不想創建一個通用的代碼塊，如下所示：

extension UIView {
    func addBorder() {  ...  }
    func addBackgroundColor() {  ...  }
}

在某些情況下，這可能是有用的；但它影響的範圍過大，會失去很多精細控制。這種類型的結構傾向成為每個 UIView 優化作業的聚集地，換句話說，這是一個龐大的代碼塊。它越龐大，其可讀性和可支持性就越差。

我使用類別——引用類型——讓 UIView 子類，遵循上述以 UIKit 為基礎的 Helper protocols (輔助協定)。通過子類化，我可以直接訪問父級 UIView 類別中的所有內容，讓我的代碼清晰、簡潔、易讀。如果我使用 struct，程式碼會更加冗長。你可以把它當成練習，試著透過實作來了解原因。

我可以做的事

請記住，所有這些 default 協定的 extensions，都可以在擴充類別 (Extended class) 被淩駕。下列範例和圖片將更詳細地解釋情況：

protocol SimpleViewWithBorder {}

extension SimpleViewWithBorder where Self : UIView {
    func addBorder() -> Void {
        layer.borderColor = UIColor.green.cgColor
        layer.borderWidth = 10.0
    }
}

class SimpleUIViewWithBorder : UIView, SimpleViewWithBorder {
    // OVERRIDE OF DEFAULT EXTENSION
    func addBorder() -> Void {
        layer.borderColor = UIColor.darkGray.cgColor
        layer.borderWidth = 20.0
    }
}

請注意在上方 SimpleUIViewWithBorder 類別中定義的註釋，看看這個 ani-GIF 的頂層視圖：

現實世界中，基於協定的 Generic (泛型) 資料結構

我為我創建的極簡化 POP 程式碼感到自豪，這些程式碼用於我的應用程式中，創建 Fully-functional 與 Generic stack 和 queue 資料結構，有關使用 Swift 泛型的背景知識，請在此閱讀我的 AppCoda 文章。

請注意，我使用協定繼承來幫助我從更抽象的 List 協定中，構建專門的 FIFO 和 LIFO 協定。然後，我利用協定擴展實現了 Queue 和 Stack 數值類型。你可以透過 Xcode 9 Playground 看到這些 struct 類型的實例。

蘋果建議透過採用其他協定來實現協定定制化，為了向你展示這個建議，我創建了 ListSubscript、ListPrintForwards、ListPrintBackwards 和 ListCount 協定，它們在這邊看起來很簡陋，但在實際的應用程式中相當實用。

這種採用多個協定的目的，是允許開發人員添加功能到程式碼基底 (Codebase)，且不會因為有太多額外、無關和/ 或不相關的功能，而造成「污染」或「膨脹」。這些 Helper 協定內，每一個成員都是獨立的。如果在繼承層級結構中，添加到 Leaf-level 以上的類別，這些功能將自動由家族樹中的其他類別繼承，具體取決於它們在樹中的位置。

我已經充分地解釋了 POP，以便你閱讀並理解此代碼。我會給你一個提示，關於如何讓我的資料結構類型變為 Generic： “Associated types:” 的定義

When defining a protocol, it’s sometimes useful to declare one or more associated types as part of the protocol’s definition. An associated type gives a placeholder name to a type that is used as part of the protocol. The actual type to use for that associated type isn’t specified until the protocol is adopted. Associated types are specified with the associatedtype keyword.

相關程式碼如下：

protocol ListSubscript {
    associatedtype AnyType
    
    var elements : [AnyType] { get }
}

extension ListSubscript {
    subscript(i: Int) -> Any {
        return elements[i]
    }
}

protocol ListPrintForwards {
    associatedtype AnyType
    
    var elements : [AnyType] { get }
}

extension ListPrintForwards {
    func showList() {
        if elements.count > 0 {
            var line = ""
            var index = 1
            
                        for element in elements {
                line += "\(element) "
                index += 1
            }
            print("\(line)\n")
        } else {
            print("EMPTY\n")
        }
    }
}

protocol ListPrintBackward {
    associatedtype AnyType
    
    var elements : [AnyType] { get }
}

extension ListPrintBackwards {
    func showList() {
        if elements.count > 0 {
            var line = ""
            var index = 1
                        
            for element in elements.reversed() {
                line += "\(element) "
                index += 1
            }
            print("\(line)\n")
        } else {
            print("EMPTY\n")
        }
    }
}

protocol ListCount {
    associatedtype AnyType
    
    var elements : [AnyType] { get }
}

extension ListCount {
    func count() -> Int {
        return elements.count
    }
}

protocol List {
    associatedtype AnyType
    
    var elements : [AnyType] { get set }
    
    mutating func remove() -> AnyType
    
    mutating func add(_ element: AnyType)
}

extension List {
    mutating func add(_ element: AnyType) {
        elements.append(element)
    }
}

protocol FIFO : List, ListCount, ListPrintForwards, ListSubscript {

}

extension FIFO {
    mutating func remove() -> AnyType {
        if elements.count > 0 {
            return elements.removeFirst()
        } else {
            return "******EMPTY******" as! AnyType
        }
    }
}

struct Queue: FIFO {
    var elements: [AnyType] = []
}

var queue = Queue()
queue.add("Bob")
queue.showList()
queue.add(1)
queue.showList()
queue.add(3.0)
_ = queue[0] // subscript gives us "Bob"
_ = queue.count()
queue.showList()
queue.remove()
queue.showList()
queue.remove()
queue.showList()
queue.remove()
queue.showList()
_ = queue.count()

protocol LIFO : List, ListCount, ListPrintBackwards, ListSubscript {
}

extension LIFO {
    mutating func remove() -> AnyType {
        if elements.count > 0 {
            return elements.removeLast()
        } else {
            return "******EMPTY******" as! AnyType
        }
    }    
}

struct Stack: LIFO {
    var elements: [AnyType] = []
}

var stack = Stack()
stack.add("Bob")
stack.showList()
stack.add(1)
stack.showList()
stack.add(3.0)
_ = stack[0] // subscript gives us 3
_ = stack.count()
stack.showList()
stack.remove()
stack.showList()
stack.remove()
stack.showList()
stack.remove()
stack.showList()
_ = stack.count()

從程式碼片段輸出的控制台畫面

Bob 

Bob 1 

Bob 1 3.0 

1 3.0 

3.0 

EMPTY

Bob 

1 Bob 

3.0 1 Bob 

1 Bob 

Bob 

EMPTY

我沒有 100％ 轉投 POP

在其中一段關於 POP 的 WWDC 視頻中，一位工程師/ 主持人說道 “We have a saying in Swift. Don’t start with a class. Start with a protocol”。嗯，也許吧，接著他開始關於使用協定來實現二分查找 (Binary search) 的冗長討論⋯⋯ 這是現在讀者最關心的問題嗎？

這聽起來像是人為設計的 POP 解決方案，也許它是有效的，也許這個解決方案有優點；我不知道。我的時間十分寶貴，沒時間來為象牙塔理論化。如果一些程式碼需要超過 5 分鐘去理解，我就知道它不符合蘋果 “Local reasoning” 原則。

如果你是像我這樣的軟體開發人員，對新方法 (技術) 保持開放態度是件好事，而管理複雜性是維持生計的中流砥柱。我絕不反對賺錢，但能全面性評估事情才是好的。請務必記住，蘋果是一家大企業，賺取大筆資金是其任務之一，它們不久前總市值達到約 837 億美元，其中包含數千億現金和約當現金。他們當然想讓每個人都加入 Swift，企業想要將人們引入其生態系統，其中一個方法就是提供獨有的產品和服務。沒錯，Swift 是開源的，但蘋果從 App Store 賺了大錢，而且這些應用程式讓 Apple 裝置變得實用，許多應用程式開發人員正轉向 Swift。

我看不到有任何理由讓開發者侷限於 POP。我認為 POP 亦有一些問題，就如我評價其他技術 (甚至 OOP) 一樣。我們正在模擬實際情境，但充其量只能讓我們接近現實，沒有完美的解決方案。就如過去多年來其他人提出的好想法般，請將 POP 放入開發人員的工具箱中。

總結

我已經有 30 年軟體開發經驗，可以冷靜將各面向的觀點提出。你應該去仔細了解協定和 POP。最重要的是，設計並編寫自己的 POP 程式碼。

我已經花了很多時間體驗 POP，並且在應用程式中使用了本文介紹的協定，例如 SimpleViewWithBorder、ViewWithBackground、ViewWithBorder、List、FIFO 以及 LIFO。POP 是個相當強大的技巧。

正如我在上一篇介紹文章提到，學習及使用像 POP 的新技術並不是一個需要取捨的命題，POP 和 OOP 不僅可以共存，而且可以相互輔助。

所以踏出一步吧，試驗、練習、學習⋯⋯ 最重要的是，讓自己充分享受生活和工作！