模式匹配第三彈: 自定義的模式匹配和語法糖

YvetteFMPU 9年前發布 | 8K 次閱讀 Swift Apple Swift開發

在模式匹配系列文章的第一彈第二彈中,我們已經看到關于 switch 搭配很多類型的用法,包括元組(tuples),范圍(Range),字符串(String),符號(Character)和一些其他類型。但是假如我們使用自定義的類型和模式匹配,又能擦出怎樣的火花呢?

Switch 和模式匹配操作符

如果你在 switch 實例中這樣寫 case 1900..<2000,那么 Swift 如何比較 switch 入口的單值與下面的范圍?

答案非常簡單:Swift 使用了 ~= 操作符。當你在 case 中使用 Range<I>時,switch 可以對 I 進行匹配,這是因為Range<I> 與 I 二者之間定義了 ~= 操作符:

func ~=<I : ForwardIndexType where I : Comparable>(pattern: Range<I>, value: I) -> Bool

事實上,如果你寫 switch someI 并加上 case aRangeOfI 語句時,Swift 會嘗試調用 aRangeOfI ~= someI 來做匹配操作(該表達式會返回一個 Bool 來通知是否匹配成功)

這就意味著你可以為自己的類型定義相同的操作符 ~=,這樣就能保證這些自定義類型可以在 switch/case 語句中使用,我們也可以用相同的方式使用 Range

讓你的自定義類型響應模式匹配

我們構造一個自定義的結構體:

struct Affine {
  var a: Int
  var b: Int
}

func ~= (lhs: Affine, rhs: Int) -> Bool {
  return rhs % lhs.a == lhs.b
}

switch 5 {
case Affine(a: 2, b: 0): print("Even number")
case Affine(a: 3, b: 1): print("3x+1")
case Affine(a: 3, b: 2): print("3x+2")
default: print("Other")
}

最終打印的結果是 3x+2

值得注意的一點是:在使用自定義類型時,Swift 不知道 switch 是否窮盡了所有可能。例如,即使我們添加了case Affine(a: 2, b: 1) 和 case Affine(a: 2, b: -1) 這兩個子句,來覆蓋到每一個正整數和負整數的情況,Swift 還是會強迫我們使用 default: 語句。

此外需要注意,不要搞混了參數的順序:~= 的第一個參數(通常稱為 lhs,譯指左手邊)是你將要在 case 子句中使用的對象,第二個參數(通常稱為 rhs,譯指右手邊)是你使用 switch 傳入的對象。

~= 的一些其他用途

~= 還有很多其他用途。

例如,我們可以在第二彈中登場的 Book 結構體中添加如下代碼:

func ~= (lhs: Range<Int>, rhs: Book) -> Bool {
  return lhs ~= rhs.year
}

現在測試一下:

let aBook = Book(title: "20,000 leagues under the sea", author: "Jules Vernes", year: 1870)
switch aBook {
case 1800..<1900: print("19th century book")
case 1900..<2000: print("20th century book")
default: print("Other century")
}

當然我不鼓勵這樣使用,將 Book 直接與一段整數范圍比較并不能很清晰地展現我們的意圖:『其實是想與 book 的出版年份進行比較』。更好的方式是在 switch 中直接傳入 aBook.year。但我們舉這個例子只是為了展示 ~= 操作符的強大(另一個原因是我暫時想不到更好的例子了)。

另一個使用 ~= 的例子是判定一個字符串是否『足夠接近』另一個。例如,你正在創作一個測試游戲,并且期望玩家通過鍵盤來輸入答案,對于玩家的答案,你希望大小寫不敏感,變音符號不敏感,甚至容忍一些小錯誤,可以像下面這樣寫:

struct Answer {
  let text: String
  let compareOptions: NSStringCompareOptions = [.CaseInsensitiveSearch, .DiacriticInsensitiveSearch, .WidthInsensitiveSearch]
}

func ~= (lhs: Answer, rhs: String) -> Bool {
  return lhs.text.compare(rhs, options: lhs.compareOptions, range: nil, locale: nil) == NSComparisonResult.OrderedSame
}

let question = "What's the French word for a face-to-face meeting?"
let userAnswer = "Tete a Tete"

switch userAnswer {
case Answer(text: "tête-à-tête"): print("Good answer!")
case Answer(text: "tête à tête"): print("Almost… don't forget dashes!")
default: print("Sorry, wrong answer!")
}
// 輸出 "Almost… don't forget dashes!"

觀察一下,這種比較是如何在一個區分大小寫,變音符合不敏感,寬度不敏感的比較中得到一個最接近的答案的。

Optionals 的語法糖

如果你認為 switch 和匹配模式的語法糖就是在 switch/case 語句中透明地使用 ~=,那只能說你們吶 too young too simple,sometimes naive

你需要了解的另一個有用的語法糖就是:當 switch 處理一個可選值 x? 時,你可以識別問號標記的可選值。

在這種特殊的環境下,使用 x? 作為語法糖來表示 .Some(x),這就意味著你可以這樣寫:

let anOptional: Int? = 2
switch anOptional {
case 0?: print("Zero")
case 1?: print("One")
case 2?: print("Two")
case nil: print("None")
default: print("Other")
}

事實上,如果你不使用 ? 而是用 case 2: 來替代 case 2?:,那么編譯器會報錯:

expression pattern of type 'Int' cannot match values of type 'Int?' 因為你嘗試將 Int(2) 和一個 Int?(可選值)進行匹配。

使用 case 2?: 其實就精準地等同于寫 case Optional.Some(2),這一過程將產生一個可選
值 Int? 包含整數 2,這樣我們就能開心地匹配另一個可選值 Int? 了。就像 anOptional. case 2?: 其實是.Some(2) 的一種更緊湊的形式。

游走在枚舉對象 rawValue 上的 Switch

提起這個,我最近構建一個 UITableView 作為菜單時,偶然發現一些代碼可以使用枚舉 enum(配合 Int 原始值 rawValue) 來組織。我們隨后可以直接操作 enum MenuItem(枚舉子菜單)而不是 indexPath.row,這個想法是不是棒極了呢!

enum MenuItem: Int {
  case Home
  case Account
  case Settings
}

隨后基于 MenuItem 來實現每一行 tableView row,代碼如下:

switch indexPath.row {
case MenuItem.Home.rawValue: …
case MenuItem.Account.rawValue: …
case MenuItem.Settings.rawValue: …
default: ()

首先,注意 switch 是如何處理 Int (indexPath.row) 并且每一行 case 如何使用 rawValue 的。這樣做是錯誤的,原因有如下幾個:

  • 首先這種寫法不會阻止你使用其他任意值,比如一個復制粘貼能使你寫出 case FooBar.Baz.rawValue 然后編譯器也不會抱怨。但是你是在處理 MenuItems,所以還是希望編譯器能夠確保我們處理的是 MenuItems,而不是其他東東。
  • 另一個問題是 switch 自身沒有窮盡所有可能,這就是為什么 default 語句是必要的。我強烈推薦你盡量不使用default 語句,而是在 switch 中窮盡所有可能,按照這種方式如果你新添加一個值到枚舉對象中,你不由自主地會強迫自己去思考如何去做而不是什么都不去想,更不會都依賴 default 來處理那些因為你懶而沒有意識的情形。

為了替代 switch 中的 indexPath 和 case ….rawValue,你應該一開始就依賴 rawValue 構建枚舉對象 enmu,通過這種方式,你在 switch 中使用枚舉對象的 cases 就足夠了,即使用 MenuItem 枚舉對象的 cases,而不是像 FooBar.Baz 之類的東東。

這樣做,因為 MenuItem(rawValue:) 是一個允許失敗的初始化程序,事實上該方法返回的也是一個可選值 MenuItem?,可以用到我們上面提到過的語法糖耶!

switch MenuItem(rawValue: indexPath.row) {
case .Home?: …
case .Account?: …
case .Settings?: …
case nil: fatalError("Invalid indexPath!")
}

老實說,對于那種情形我更習慣使用 guard let,而且我發現這種方式比在每個 case 中使用 ? 更具可讀性:

guard let menuItem = MenuItem(rawValue: indexPath.row) else { fatalError("Invalid indexPath!") }
switch menuItem {
case .Home: …
case .Account: …
case .Settings: …
}

是不是有點靈活,了解一下所有可能的選擇總歸不是一件壞事。

總結

這就是今天我要說的,在這一系列文章的下一篇(或許是最后一篇)中,我會說說如何在其他場景下使用模式匹配。我們不會局限在 switch 上,會講講在 ifguard 和 for 循環中如何使用模式匹配,并將大家對模式匹配的認識提升到一個新的高度,讓我們拭目以待吧。

來源:http://swift.gg/2016/04/28/pattern-matching-3/

 本文由用戶 YvetteFMPU 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!