模式匹配第三彈: 自定義的模式匹配和語法糖
在模式匹配系列文章的第一彈和第二彈中,我們已經看到關于 switch 搭配很多類型的用法,包括元組(tuples),范圍(Range),字符串(String),符號(Character)和一些其他類型。但是假如我們使用自定義的類型和模式匹配,又能擦出怎樣的火花呢?
Switch 和模式匹配操作符
如果你在 switch 實例中這樣寫 case 1900..<2000,那么 Swift 如何比較 switch 入口的單值與下面的范圍?
答案非常簡單:Swift 使用了 ~= 操作符。當你在 case 中使用 Range<I>時,switch 可以對 I 進行匹配,這是因為Range<I> 與 I 二者之間定義了 ~= 操作符:
|
事實上,如果你寫 switch someI 并加上 case aRangeOfI 語句時,Swift 會嘗試調用 aRangeOfI ~= someI 來做匹配操作(該表達式會返回一個 Bool 來通知是否匹配成功)
這就意味著你可以為自己的類型定義相同的操作符 ~=,這樣就能保證這些自定義類型可以在 switch/case 語句中使用,我們也可以用相同的方式使用 Range!
讓你的自定義類型響應模式匹配
我們構造一個自定義的結構體:
|
最終打印的結果是 3x+2!
值得注意的一點是:在使用自定義類型時,Swift 不知道 switch 是否窮盡了所有可能。例如,即使我們添加了case Affine(a: 2, b: 1) 和 case Affine(a: 2, b: -1) 這兩個子句,來覆蓋到每一個正整數和負整數的情況,Swift 還是會強迫我們使用 default: 語句。
此外需要注意,不要搞混了參數的順序:~= 的第一個參數(通常稱為 lhs,譯指左手邊)是你將要在 case 子句中使用的對象,第二個參數(通常稱為 rhs,譯指右手邊)是你使用 switch 傳入的對象。
~= 的一些其他用途
~= 還有很多其他用途。
例如,我們可以在第二彈中登場的 Book 結構體中添加如下代碼:
|
現在測試一下:
|
當然我不鼓勵這樣使用,將 Book 直接與一段整數范圍比較并不能很清晰地展現我們的意圖:『其實是想與 book 的出版年份進行比較』。更好的方式是在 switch 中直接傳入 aBook.year。但我們舉這個例子只是為了展示 ~= 操作符的強大(另一個原因是我暫時想不到更好的例子了)。
另一個使用 ~= 的例子是判定一個字符串是否『足夠接近』另一個。例如,你正在創作一個測試游戲,并且期望玩家通過鍵盤來輸入答案,對于玩家的答案,你希望大小寫不敏感,變音符號不敏感,甚至容忍一些小錯誤,可以像下面這樣寫:
|
觀察一下,這種比較是如何在一個區分大小寫,變音符合不敏感,寬度不敏感的比較中得到一個最接近的答案的。
Optionals 的語法糖
如果你認為 switch 和匹配模式的語法糖就是在 switch/case 語句中透明地使用 ~=,那只能說你們吶 too young too simple,sometimes naive。
你需要了解的另一個有用的語法糖就是:當 switch 處理一個可選值 x? 時,你可以識別問號標記的可選值。
在這種特殊的環境下,使用 x? 作為語法糖來表示 .Some(x),這就意味著你可以這樣寫:
|
事實上,如果你不使用 ? 而是用 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,這個想法是不是棒極了呢!
|
隨后基于 MenuItem 來實現每一行 tableView row,代碼如下:
|
首先,注意 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?,可以用到我們上面提到過的語法糖耶!
|
老實說,對于那種情形我更習慣使用 guard let,而且我發現這種方式比在每個 case 中使用 ? 更具可讀性:
|
是不是有點靈活,了解一下所有可能的選擇總歸不是一件壞事。
總結
這就是今天我要說的,在這一系列文章的下一篇(或許是最后一篇)中,我會說說如何在其他場景下使用模式匹配。我們不會局限在 switch 上,會講講在 if, guard 和 for 循環中如何使用模式匹配,并將大家對模式匹配的認識提升到一個新的高度,讓我們拭目以待吧。
來源:http://swift.gg/2016/04/28/pattern-matching-3/