風(fēng)騷的Guard語法
Swift 2.0 帶來了令人激動(dòng)的guard語句。但很多人還是不太理解guard的意義,特別是和 Swift 2.0 之前的簡單if語句相比較。
本文引用地址:http://2s4d.com/article/201609/303409.htm為什么guard就是比if要好呢?
與if語句相同的是,guard也是基于一個(gè)表達(dá)式的布爾值去判斷一段代碼是否該被執(zhí)行。與if語句不同的是,guard只有在條件不滿足的時(shí)候才會(huì)執(zhí)行這段代碼。你可以把guard近似的看做是Assert,但是你可以優(yōu)雅的退出而非崩潰。
具體細(xì)節(jié)
讓我們用一個(gè)簡單的對比來比較一下現(xiàn)在的寫法和用全新guard語句的寫法:
func fooManualCheck(x: Int?) {
if x == nil || x = 0 {
// 不符合值的要求時(shí),寫點(diǎn)代碼
return
}
// 使用x
x!.description
}
這是最基本的Objective-C方式來保證一個(gè)變量真的存在并符合一個(gè)條件。沒什么大問題,但是有一些缺點(diǎn):
你是在檢查一個(gè)不符合你期望的條件,而非檢查你想要的值。如果你加了一堆像這樣的條件判斷,代碼就變的不好理解。你在這里其實(shí)是等著你的條件通不過。
如果前面條件判斷的結(jié)果不符合了,你還得將你的變量強(qiáng)制拆包。
Swift通過可選綁定讓問題變得簡單了一些,并解決了上面的部分缺點(diǎn):
func fooBinding(x: Int?) {
if let x = x where x > 0 {
// 使用x
x.description
}
// 如果值不符合條件判斷,就執(zhí)行下面的代碼
}
這個(gè)函數(shù)沒有了第一個(gè)函數(shù)的2個(gè)缺陷,但引入了一個(gè)新的。你把你要寫的代碼都放在了所有條件判斷中,而不是之后。你可能不會(huì)馬上意識到這個(gè)問題,但是你可以想象在你的代碼被執(zhí)行之前,如果嵌套了好多需要被匹配的條件判斷,這會(huì)變的多難讀懂。
對此的解決方法是先對每個(gè)條件逐一做檢查,如果不符合條件判斷就退出。這就會(huì)讓人容易看出來什么條件會(huì)讓這個(gè)函數(shù)退出。
我聽說過這個(gè)叫保鏢模式(Bouncer Pattern),這個(gè)模式十分的合理。你要在壞情況進(jìn)門之前把它們擋出去。這讓你每次只考慮一種情況,而不用去搞清楚如何同時(shí)將所有的條件判斷安排在一起。
這就是guard語句:
func fooGuard(x: Int?) {
guard let x = x where x > 0 else {
// 變量不符合條件判斷時(shí),執(zhí)行下面代碼
return
}
// 使用x
x.description
}
使用guard語句將上述的3個(gè)問題一并解決:
是對你所期望的條件做檢查,而非不符合你期望的。又是和assert很相似。如果條件不符合,guard的else語句就運(yùn)行,從而退出這個(gè)函數(shù)。
如果通過了條件判斷,可選類型的變量在guard語句被調(diào)用的范圍內(nèi)會(huì)被自動(dòng)的拆包 - 這個(gè)例子中該范圍是fooGuard函數(shù)內(nèi)部。這是一個(gè)很重要,卻有點(diǎn)奇怪的特性,但讓guard語句十分實(shí)用。
對你所不期望的情況早做檢查,使得你寫的函數(shù)更易讀,更易維護(hù)。
對非可選類型的變量這種用法也是奏效的:
func fooNonOptionalGood(x: Int) {
guard x > 0 else {
// 變量不符合條件判斷時(shí),執(zhí)行下面代碼
return
}
// 使用x
}
func fooNonOptionalBad(x: Int) {
if x = 0 {
// 變量不符合條件判斷時(shí),執(zhí)行下面代碼
return
}
// 使用x
}
再給一個(gè)示例對比,使用guard和if
總結(jié)
希望上面這個(gè)簡單的例子告訴你可以馬上在你的swift代碼中使用guard,從而讓你的函數(shù)/方法更清楚。
評論