Swift之深入決議如何自定義運算子

一、Swift 運算子

• 運算子是一個符號，用于告訴編譯器執行一個數學或邏輯運算，
• Swift 提供了以下幾種運算子：
• • 算術運算子
• • 比較運算子
• • 邏輯運算子
• • 位運算子
• • 賦值運算子
• • 區間運算子
• • 其它運算子

① 算術運算子

• 如下所示，列出了 Swift 語言支持的算術運算子，其中變數 A 為 10，變數 B 為 20：

• Swift 中已經取消 ++、–，

② 比較運算子

• 如下所示，列出了 Swift 語言支持的比較運算子，其中變數 A 為 10，變數 B 為 20：

③ 邏輯運算子

• 如下所示，列出了 Swift 語言支持的邏輯運算子，其中變數 A 為 true，變數 B 為 false：

④ 位運算子

• 位運算子用來對二進制位進行操作，~,&,|,^ 分別為取反，按位與與，按位與或，按位與異或運算，如下表：

• 如果指定 A = 60; 及 B = 13; 兩個變數對應的二進制為：

A = 0011 1100

B = 0000 1101

• 進行位運算：

⑤ 賦值運算

• 如下所示，列出了 Swift 語言的基本賦值運算：

⑥ 區間運算子

• Swift 提供了兩個區間的運算子：

⑦ 其它運算子

• Swift 提供了其它型別的的運算子，如一元、二元和三元運算子：
• • 一元運算子對單一操作物件操作（如 -a），一元運算子分前置運算子和后置運算子，前置運算子需緊跟在操作物件之前（如 !b），后置運算子需緊跟在操作物件之后（例如 c!），備注：在 Java/C 沒有類似 c！的語法， 在 Swift 中用在 Optional 型別取值；
• • 二元運算子操作兩個操作物件（如2 + 3），是中置的，因為它們出現在兩個操作物件之間；
• • 三元運算子操作三個操作物件，和 C 語言一樣，Swift 只有一個三元運算子，就是三目運算子（a ? b : c），

二、自定義運算子

① 數字容器

• 有時定義了實質上只是容器的值型別其容納著更加原始的值，例如，在一個戰略游戲中，玩家可以收集兩種資源：木材和金幣，要在代碼中建模這些資源，可以使用作為木材和金幣值的容器的 Resource 結構體，如下所示：

struct Resources {
    var gold: Int
    var wood: Int
}

• 每當參考一組資源時，就會使用此結構，例如，要跟蹤玩家當前可用的資源：

struct Player {
    var resources: Resources
}

• 可以在游戲中花費資源的一件事是為隊伍培訓新單位，執行此類動作時，只需從當前的玩家的資源中減去該單元的金幣和木材成本：

func trainUnit(ofKind kind: Unit.Kind) {
    let unit = Unit(kind: kind)
    board.add(unit)

    currentPlayer.resources.gold -= kind.cost.gold
    currentPlayer.resources.wood -= kind.cost.wood
}

• 做到上面的完全有效，但由于游戲中有許多影響玩家資源的動作，代碼中有許多地方必須重復金幣和木頭的兩個減法，這不僅使得很容易忘記減少其中一個值，同時它還使得引入一種新的資源型別更難（例如，銀幣），因為必須通過查看整個代碼并更新所有處理資源的地方，

② 運算子多載

• 現在嘗試使用運算子多載來解決上述問題，使用大多數語言（包括 Swift）的運算子時，都有兩個選項，多載現有運算子，或者創建一個新的運算子，多載作業就像方法多載，可以使用新的輸入或輸出創建新版本的運算子，
• 在這種情況下，將定義 -= 運算子的過載，它們適用于兩個 Resources 值，如下所示：

extension Resources {
    static func -=(lhs: inout Resources, rhs: Resources) {
        lhs.gold -= rhs.gold
        lhs.wood -= rhs.wood
    }
}

• 就像遵守 Equatable 協議的時候一樣，Swift 中的運算子多載只是可以在型別上宣告的一個正常靜態函式，在此處 -= 中，運算子的左側是一個 inoiut 引數，這是需要修改的值，通過運算子多載，現在可以直接在當前的玩家的資源上簡單地呼叫 -= ，就像將其放在在任何原始數值上：

currentPlayer.resources -= kind.cost

• 這不僅很好閱讀，它還有助于我們消除代碼重復問題，由于總是希望所有外部邏輯修改完整的 Resource 實體，因此可以將金幣 gold 和木材 wood 屬性作為只讀屬性開放給外部其它類：

struct Resources {
    private(set) var gold: Int
    private(set) var wood: Int

    init(gold: Int, wood: Int) {
        self.gold = gold
        self.wood = wood
    }
}

③ 可變函式

• 另一種可以解決上面的 Resources 問題的方法是使用可變函式而不是運算子多載，添加一個函式，通過另一個實體減少 Resources 值的屬性，如下所示：

extension Resources {
    mutating func reduce(by resources: Resources) {
        gold -= resources.gold
        wood -= resources.wood
    }
}

• 這兩個解決方案都有它們的優點，可以爭辯說可變函式方法更明確，但是，我們不希望數學的標準減法 API 變成：5.reduce(by: 3)，所以也許這是一個運算子多載表現完美的地方，

④ 布局計算

• 來看看另一種方案，其中使用運算子多載可能非常好，盡管擁有自動布局和強大的布局 API，但有時發現自己在某些情況下需要進行手動布局計算，
• 在這樣的情況下，它非常常見，必須在二維值上進行數學操作，如 CGPoint，CGSize 和 CGVector，例如，我們可能需要通過使用影像視圖的大小和一些額外的邊距來計算標簽的原點，如下所示：

label.frame.origin = CGPoint(
    x: imageView.bounds.width + 10,
    y: imageView.bounds.height + 20
)

• 如果可以簡單地添加它們，而不是必須始終展開 point 和 size 來使用它們的底層組件，這會不會很好（就像上面對 Resources 的操作一樣）?
• 為了能夠這樣做，可以通過多載 + 運算子來接受兩個 CGSize 實體作為輸入，并輸出 CGPoint 值：

extension CGSize {
    static func +(lhs: CGSize, rhs: CGSize) -> CGPoint {
        return CGPoint(
            x: lhs.width + rhs.width,
            y: lhs.height + rhs.height
        )
    }
}

• 通過上面的代碼，現在可以寫下布局計算：

label.frame.origin = imageView.bounds.size + CGSize(width: 10, height: 20)

• 這很酷，但必須為我們的位置創造 CGSize 會感到有點奇怪，使這個有點更好的一種方法可以是定義另一個 + 多載，該 + 多載接受包含兩個 CGFloat 值的元組，如下所示：

extension CGSize {
    static func +(lhs: CGSize, rhs: (x: CGFloat, y: CGFloat)) -> CGPoint {
        return CGPoint(
            x: lhs.width + rhs.x,
            y: lhs.height + rhs.y
        )
    }
}

• 這讓我們在這兩種方式中的任何一個寫下布局計算：

// 使用元組標簽:
label.frame.origin = imageView.bounds.size + (x: 10, y: 20)

// 或者不寫:
label.frame.origin = imageView.bounds.size + (10, 20)

• 但現在我們正在接近導致運算子的爭論出現的核心問題：平衡冗余程度和可讀性，由于仍然處理數字，我認為大多數人會發現上面的易于閱讀和理解，但隨著繼續自定義運算子的用途，它變得更加復雜，特別是當我們開始引入全新的運算子時，

⑤ 用于處理錯誤的自定義運算子

• 到目前為止，還只是簡單的多載了系統已經存在的運算子，但是，如果想開始使用無法真正映射到現有的功能的運算子，我們需要定義自己的，
• Swift 的 do，try，catch 錯誤處理機制在處理無法使用的同步操作時超級漂亮，它可以在出現錯誤后，輕松安全地退出函式，例如在加載磁盤上保存的資料模型時：

class NoteManager {
    func loadNote(fromFileNamed fileName: String) throws -> Note {
        let file = try fileLoader.loadFile(named: fileName)
        let data = try file.read()
        let note = try Note(data: data)
        return note
    }
}

• 做出像上面的唯一主要的缺點是我們直接向我們功能的呼叫者拋出出任何潛在的錯誤，需要減少 API 可以拋出的錯誤量，否則做有意義的錯誤處理和測驗變得非常困難，
• 理想情況下，我們想要的是給定 API 可以拋出的有限錯誤，這樣就可以輕松地單獨處理每種情況，假設我們也想捕獲所有潛在的錯誤，這給了我們最好的兩個世界，因此，使用顯式 cases 定義一個錯誤列舉，每個錯誤的列舉都使用底層錯誤的關聯值，如下所示：

extension NoteManager {
    enum LoadingError: Error {
        case invalidFile(Error)
        case invalidData(Error)
        case decodingFailed(Error)
    }
}

• 但是，捕獲潛在的錯誤并將它們轉換為自己型別是棘手的，我們必須寫下類似的標準錯誤處理機制：

class NoteManager {
    func loadNote(fromFileNamed fileName: String) throws -> Note {
        do {
            let file = try fileLoader.loadFile(named: fileName)

            do {
                let data = try file.read()

                do {
                    return try Note(data: data)
                } catch {
                    throw LoadingError.decodingFailed(error)
                }
            } catch {
                throw LoadingError.invalidData(error)
            }
        } catch {
            throw LoadingError.invalidFile(error)
        }
    }
}

• 我并不認為有人想要閱讀像上面的代碼，一個選項是介紹一個 perform 函式，可以用來把一個錯誤轉換為另一個錯誤：

class NoteManager {
    func loadNote(fromFileNamed fileName: String) throws -> Note {
        let file = try perform(fileLoader.loadFile(named: fileName),
                               orThrow: LoadingError.invalidFile)

        let data = try perform(file.read(),
                               orThrow: LoadingError.invalidData)

        let note = try perform(Note(data: data),
                               orThrow: LoadingError.decodingFailed)

        return note
    }
}

func perform<T>(_ expression: @autoclosure () throws -> T,
                errorTransform: (Error) -> Error) throws -> T {
    do {
        return try expression()
    } catch {
        throw errorTransform(error)
    }
}

• 現在就好多了，但是仍然有很多錯誤轉換代碼擾亂了實際邏輯，讓我們來看看引入一個新的運算子是否能幫助我們稍微清理一下這段代碼，

⑥ 添加新的運算子

• 首先定義我們的新運營商，在這種情況下，將選擇 ?> 作為符號（具有替代回傳型別的動機，所以正在尋找類似于 ->）的東西，由于這是一個將在兩側作業運算子，因此將其定義為 infix，如下所示：

infix operator ~>

• 使運算子如此強大的是它們可以自動捕捉它們兩側的背景關系，將其與Swift 的 @autoclosure 功能相結合，可以創建一些非常酷的東西，來實作 ?> 作為傳遞運算式和轉換錯誤的運算子，拋出或回傳與原始運算式相同的型別：

func ~><T>(expression: @autoclosure () throws -> T,
           errorTransform: (Error) -> Error) throws -> T {
    do {
        return try expression()
    } catch {
        throw errorTransform(error)
    }
}

• 那么上述這個運算子能夠讓我們做什么呢？由于列舉具有關聯值的靜態函式在 Swift 中也是靜態函式，可以簡單地在我們的拋出運算式和錯誤情況之間添加 ?> 運算子，我們希望將任何底層錯誤轉換為如下形式：

class NoteManager {
    func loadNote(fromFileNamed fileName: String) throws -> Note {
        let file = try fileLoader.loadFile(named: fileName) ~> LoadingError.invalidFile
        let data = try file.read() ~> LoadingError.invalidData
        let note = try Note(data: data) ~> LoadingError.decodingFailed
        return note
    }
}

• 這就很好了，通過使用運算子，已從我們的邏輯中洗掉了大量的繁瑣代碼和語法，使代碼更為聚焦，然而，缺點是引入了一個新的錯誤處理語法，這可能是任何可能在未來加入專案的新開發人員完全不熟悉的，

三、總結

• 自定義運算子和運算子多載是一個非常強大的功能，可以讓我們構建非常有趣的解決方案，它可以讓我們降低呈現型函式呼叫的冗長，這可能會給我們清潔代碼，
• 然而，它也可以是一個滑坡，可以引導我們撰寫隱秘的和難以閱讀的代碼，這對其他開發人員來說變得非常令人恐懼和混淆，