一年前，在 Swift 推出不久后，我觀察到許多 iOS 開發(fā)者仍然以 Objective-C 的開發(fā)習(xí)慣來寫 Swift。而在我眼中，Swift 是一門全新的語言，有別于 Objective-C 的語法、設(shè)計哲學(xué)乃至發(fā)展?jié)摿?#xff0c;因此我們更應(yīng)探索出一條屬于 Swift 獨有風(fēng)格的發(fā)展道路。我在之前的文章?Swifty methods?中已經(jīng)探討過在 Swift 中如何清晰、明確地對方法進行命名，隨后我開始連載?Swifty API?系列文章，同時將這一想法付諸實踐，探索如何設(shè)計更加簡單易用的接口 API。

在該系列（Swifty API）第一篇文章中，我們對?NSUserDefaults?API 進行了改造：

NSUserDefaults.standardUserDefaults().stringForKey("color") NSUserDefaults.standardUserDefaults().setObject("red", forKey: "color")

改造之后看上去像這樣：

Defaults["color"].string Defaults["color"] = "red"

相較之前的 get 和 set 方法，改造后的結(jié)果更加簡單明了，同時也修正了一致性問題，使其更符合 Swift 的使用風(fēng)格。這看上去是相當(dāng)大的改進。

但是，隨著我對 Swift 深入學(xué)習(xí)，以及真正在項目中使用這些由我親手締造的 API 后，我才意識到這些 API 離真正的原生 Swift 風(fēng)格還有相當(dāng)大的差距。在之前的 API 設(shè)計中，我從 Ruby 和 Swift 的語法中汲取靈感來構(gòu)建自己的 API，這一點雖然值得肯定，但是我們并沒有將其真正提升到語義學(xué)的高度。僅僅是在外表裹了層 Swift 風(fēng)格的外衣，而內(nèi)部機制仍然是以 Objective-C 的形式在運作。

缺點

「API 不是那么 Swift 化」，聽上去并不是一個讓我們從頭開始的好理由，雖然相似的 API 更容易學(xué)習(xí)，但我們不想這么教條。我們不僅僅想要設(shè)計出來的 API 看上去更加 Swift 化，還希望能在 Swift 的運行機制下更好地工作。這樣看來，我們之前設(shè)計的?NSUserDefaults?存在一些小問題：

假設(shè)你有一個關(guān)于用戶喜好顏色的設(shè)置選項：

Defaults["color"] = "red" // App 中的其他一處： Defaults["colour"].string // => nil

啊哦，一旦不小心把鍵名（key name）寫錯了，就會出現(xiàn) Bug :(

同理我們放一個?date?對象到?defaults?中：

Defaults["deadline"] = NSDate.distantFuture() Defaults["deadline"].data // => nil

這一次在?getter?方法中把?date?拼錯成了?data，結(jié)果是?nil，又獲得 bug 一枚。你或許認(rèn)為這種情況并不會經(jīng)常發(fā)生，但為什么每次我們要對取回（getter）的對象指定類型呢？這確實有點煩人。

再來一個例子（這個例子我們在賦值的時候就錯了，取回的結(jié)果當(dāng)然是?nil）：

Defaults["deadline"] = NSData() Defaults["deadline"].date // => nil

顯然我們想要「現(xiàn)在的時間」的日期而不是一個「空的data值」！

最后觀察下面的代碼：

Defaults["magic"] = 3.14 Defaults["magic"] += 10 Defaults["magic"] // => 13

在第一篇文章中，我們重新定義了?+=，使其能夠在我的新 API 下正常工作，但這兒有個缺陷：只能從傳遞進來的參數(shù)進行類型推斷（Int?or?Double）。也就是說如果你參數(shù)傳一個整數(shù)（Int）10，運算后的結(jié)果是 13.14（Double）類型，但最終返回的結(jié)果還是會以上一次傳入的參數(shù)類型為基準(zhǔn)，決定最終的返回值。這個例子最后返回值為 13，砍掉了小數(shù)部分，顯然是個 bug。

你又或許認(rèn)為以上都是純理論問題，在真實世界里并不會發(fā)生。先別著急下結(jié)論，仔細(xì)想想，這些拼錯變量名、方法名和傳遞一個錯誤類型的參數(shù)其實都可以歸為同一類型的 bug，而這些 bug 在日常開發(fā)中是常有之事。如果你正在使用一門需要編譯的靜態(tài)類型語言，那么你更應(yīng)該依賴編譯器給你的反饋而不是事后去測試，更重要的是，花費精力在編譯期進行檢查也會在將來給你帶來豐厚的紅利，這不僅僅是在首次寫代碼時才能享受這種編譯器檢查帶來的好處，在之后的重構(gòu)中，你也能減少很多不必要的 bug。這里提供一些小建議，可以讓未來的你免受 bug 之苦。

靜態(tài)類型的力量

導(dǎo)致這些問題的根源在于：沒有定義關(guān)于 user defaults 的靜態(tài)結(jié)構(gòu)。

在早先的設(shè)計中，我意識到這個問題，于是將各種類型封裝在了?NSUserDefaults?內(nèi)部的?Proxy?對象中。調(diào)用時你可以通過下標(biāo)（subscript）獲得一個?Proxy?對象，然后再通過 Proxy 提供的訪問方法來實現(xiàn)特定類型的訪問。

Defaults["color"].string Defaults["launchCount"].int

采用上面這種方式，比你自己實現(xiàn)?getter?方法或手動對?AnyObject?類型轉(zhuǎn)換要好很多。

但這是一個 hack，并不算真正的解決方案。為了對 API 實現(xiàn)真正意義上的改進，我們需要收集有關(guān) user default keys 的信息，之后提供給編譯器。

現(xiàn)在回想下那位長者傳授給我們的人生經(jīng)驗。通常不變的常量字符串，為了避免拼寫錯誤，會在一開始就以?string keys?的形式定義，隨后使用時編譯器也會自動補全：

let colorKey = "color"

讓我們帶上類型信息：

class DefaultsKey<ValueType> { let key: String init(_ key: String) { self.key = key } } let colorKey = DefaultsKey<String?>("color")

我們將 key name 封裝在一個對象中，并且將值類型植入到泛型參數(shù)中。現(xiàn)在我們可以定義一個新的?NSUserDefaults?下標(biāo)，用來接收這些 keys：

extension NSUserDefaults { subscript(key: DefaultsKey<String?>) -> String? { get { return stringForKey(key.key) } set { setObject(newValue, forKey: key.key) } } }

這里是結(jié)果：

let key = DefaultsKey<String?>("color") Defaults[key] = "green" Defaults[key] // => "green", typed as String?

沒錯，就這么簡單，語法和功能稍后再來完善。我們通過這個小技巧，修復(fù)了許多問題。比如沒辦法再輕易拼錯 key name 了，因為他只能定義一次。也不能隨便就賦值一個不匹配的類型了，因為你這么做編譯器會報錯。最后也不必寫?.string，因為編譯器已經(jīng)知道我們想要的類型了。

此外，我們或許應(yīng)該使用泛型來定義?NSUserDefaults?的下標(biāo)（subscripts），而不是手動輸入所有需要的類型。不過想法總是美好的,現(xiàn)實卻是殘酷的，Swift 的編譯器目前還不支持泛型下標(biāo)。(╯‵□′)╯︵┻━┻ 方括號可能看上去還不錯，別再糾結(jié)語法了，我們讓 setting 和 getting 方法更加泛型化就好了。

等等，你還沒有見識過下標(biāo)?subscripts?的能耐！

令人振奮的下標(biāo)

考慮下面這種寫法：

var array = [1, 2, 3] array.first! += 10

完全不能通過編譯！我們嘗試對數(shù)組內(nèi)部的整數(shù)進行加法操作，但這對于 Swift 來說是做不到的。整數(shù)具有值語義，是不可變的。當(dāng)他們從某些地方返回時，你不能直接去修改他們的值，這是因為他們并不存在于表達式之外，僅算是瞬時狀態(tài)下的一份拷貝罷了。

改換變量來做就沒問題：

var number = 1 number += 10

注意，實際并沒有真正意義上改變 1 這個整數(shù)，而只是修改了變量，為其分配了一個新值而已。

再來看看下面這段代碼：

var array = [1, 2, 3] array[0] += 10 array // => [11, 2, 3]

結(jié)果終于如你所愿了，不是嗎？這和你想象中的一樣，可是為什么這么做就可以了呢？

觀察一下，在 Swift 中，下標(biāo)和里面的值類型似乎也合作地非常愉快。我們可以通過下標(biāo)來修改數(shù)組里的值，是因為他在內(nèi)部實現(xiàn)了?getter?和?setter?方法。編譯器層面所做的工作是將?array[0] += 10重寫為?array[0] = array[0] + 10。如果你只實現(xiàn)了?getter?下標(biāo)?subscript，而沒有實現(xiàn)?setter，是不會正常工作的。

這不僅僅是數(shù)組（Array）特有的黑魔法，這是下標(biāo)（subscript）語義精心設(shè)計后的結(jié)果，我們可以在自己實現(xiàn)的?subscripts?免費獲得這種特性，比如我們還可以這么玩：

Defaults[launchCountKey]++ Defaults[volumeKey] -= 0.1 Defaults[favoriteColorsKey].append("green") Defaults[stringKey] += "… can easily be extended!"

有意思吧，要知道在 API 1.0 版本，我們僅僅模仿字典那樣使用下標(biāo)，并沒有利用上面介紹的這種語義。

我們還添加了一些?+=、++?這樣的操作符，但是這種行為比較危險，主要依賴于編譯器的魔法實現(xiàn)。在這里我們通過將類型信息封裝在 key 中，然后定義了?subscript?的?getter?和?setter?方法，現(xiàn)在整個世界看上去運轉(zhuǎn)正常。

捷徑

在老版本 API 設(shè)計中，使用字符串 key 的好處在于你可以按需使用，而不用去創(chuàng)建任何中間對象。

而在目前改進的新版本中，每次使用前都要創(chuàng)建鍵對象（key object）好像沒什么道理，況且這會帶來可怕的重復(fù)以及抵消掉靜態(tài)類型帶來的好處。所以讓我們再想想如何能夠更好地組織?defaults keys：

一種解決方案就是在類層級（class level）定義這些 keys：

class Foo { struct Keys { static let color = DefaultsKey<String>("color") static let counter = DefaultsKey<Int>("counter") } func fooify() { let color = Defaults[Keys.color] let counter = Defaults[Keys.counter] } }

這似乎已經(jīng)是 Swift 關(guān)于字符型 keys 的標(biāo)準(zhǔn)實踐了。

另一種解決方案是利用 Swift 的隱式成員表達式，此功能的最常見用途是枚舉。當(dāng)一個方法需要一個枚舉類型?Direction?作為參數(shù)，你可以傳遞?.Right。編譯器能夠推斷出真正的參數(shù)類型Direction.Right。這里有個冷知識：這種特性（隱式成員表達式）同樣適用于方法參數(shù)是靜態(tài)成員類型的情形，例如你可以在一個需要?CGRect?類型做參數(shù)的方法中，使用?.zeroRect?來代替?CGRect.zeroRect。

事實上，我們可以通過把鍵定義為?DefaultsKey?上的靜態(tài)常量來做相同的事情。好啦，差不多了，最后為了消除編譯器上的限制，我們需要一個稍微不同的定義：

class DefaultsKeys {} class DefaultsKey<ValueType>: DefaultsKeys { ... } extension DefaultsKeys { static let color = DefaultsKey<String>("color") }

試一下效果，哇，不錯哦！

Defaults[.color] = "red"

是不是很炫酷？站在調(diào)用者的角度，現(xiàn)在比之前用傳統(tǒng)字符串的方式顯得不再那么冗余，開發(fā)者的代碼量減少了，讀起來也更直觀。有沒有感到很興奮，如果我告訴你這一切都是免費獲得的，你會不會更開心。

（這項技術(shù)的一個缺陷就是沒有命名空間機制，在大工程中還是老實采用鍵結(jié)構(gòu)體?Keys struct?的方式更好一些。）

可選值難題

在前一版設(shè)計的 API 中，我們讓所有的 getters 都返回可選值，不過我不大喜歡?NSUserDefaults?處理不同類型時缺乏一致性，對于字符串，缺失值將返回?nil，但是對于數(shù)字和布爾值，你將會得到?0?和?false。

我很快意識到這種方式缺點是太冗長。大多數(shù)時候我們并不關(guān)心?nil?的情形，只希望在這種情況下得到一個默認(rèn)值，僅此而已。而每次我們通過下標(biāo)（subscripts）獲得一個可選值后，都要先解封包做判斷，再決定返回解包值還是預(yù)設(shè)的默認(rèn)值。

Oleg Kokhtenko 針對這個問題提出了解決方案，除了標(biāo)準(zhǔn)的可選返回值的?getter?方法，我們還添加了一組?getter?方法，這些方法都以標(biāo)志性的?-Value?結(jié)尾，并且結(jié)果為?nil?時會返回默認(rèn)值代替，這樣類型更加明確：

Defaults["color"].stringValue // 默認(rèn)得到"" Defaults["launchCount"].intValue // 默認(rèn)得到0 Defaults["loggingEnabled"].boolValue // 默認(rèn)得到false Defaults["lastPaths"].arrayValue // 默認(rèn)得到[] Defaults["credentials"].dictionaryValue // 默認(rèn)得到[:] Defaults["hotkey"].dataValue // 默認(rèn)得到NSData()

我們可以在靜態(tài)類型體制下做同樣的事情，下面為 optional 和非 optional 類型各提供一個?subscript?變體。

extension NSUserDefaults { subscript(key: DefaultsKey<NSData?>) -> NSData? { get { return dataForKey(key.key) } set { setObject(newValue, forKey: key.key) } } subscript(key: DefaultsKey<NSData>) -> NSData { get { return dataForKey(key.key) ?? NSData() } set { setObject(newValue, forKey: key.key) } } }

我喜歡這么做，因為這樣就不用依賴協(xié)定約定（type?和?typeValue），將空值轉(zhuǎn)換為各種類型的默認(rèn)值。而是使用已經(jīng)在 user defaults key 中定義好的類型，剩下的工作就交給編譯器吧。

更多的類型

我通過添加這些類型的下標(biāo)來擴大支持的類型范圍：String，Int，Double，Bool，NSData，[AnyObject]，[String: AnyObject]，NSString，NSArray，NSDictionary（還包含他們的可選變體，注意?NSDate?，NSURL?，AnyObject??沒有對應(yīng)的非可選部分，因為這些類型的默認(rèn)值沒有意義）。

還要注意一點，字符串（strings）、字典（dictionaries）和數(shù)組（arrays）同時存在于 Swift 基本庫和 Cocoa Foundation 框架中。而我們優(yōu)先考慮 Swift 原生類型，但這些類型并不具備他們在 Cocoa 框架中的一些能力，不過如果真正需要，我會讓事情簡單一些。

提到數(shù)組，為什么把我們只限制沒有類型化的數(shù)組？因為在大多數(shù)情況下，user defaults?中存儲的數(shù)組里面的元素都是同一類型的，比如?String，Int，NSData。

因為不能定義泛型下標(biāo)，我們來創(chuàng)建一對泛型?helper?方法：

extension NSUserDefaults { func getArray<T>(key: DefaultsKey<[T]>) -> [T] { return arrayForKey(key.key) as? [T] ?? [] } func getArray<T>(key: DefaultsKey<[T]?>) -> [T]? { return arrayForKey(key.key) as? [T] } }

復(fù)制、粘貼，然后參照下面這段代碼改寫所有我們感興趣的類型：

extension NSUserDefaults { subscript(key: DefaultsKey<[String]?>) -> [String]? { get { return getArray(key) } set { set(key, newValue) } } }

現(xiàn)在可以這樣調(diào)用：

let key = DefaultsKey<[String]>("colors") Defaults[key].append("red") let red = Defaults[key][0]

我們通過數(shù)組下標(biāo)返回一個?String，然后為其添加了一個字符串，整個驗證過程發(fā)生在了編譯期（編譯器會對進行的操作進行類型檢查），這樣做更加安全便捷。

歸檔

NSUserDefaults?還有一個缺點是支持的類型并不多，如果我們想存儲自定義的類型，通用的解決辦法是用?NSKeyedArchiver?來序列化你的自定義對象。

接下來我們努力把世界變得更美好一點，類似于?getArray?的 helper 方法，我定義了?archive()?和?unarchive()?的泛型方法，這樣我就能很容易地設(shè)計一段下標(biāo)代碼來處理各種自定義類型（前提是這些類型遵循 NSCoding 協(xié)議）。

extension NSUserDefaults { subscript(key: DefaultsKey<NSColor?>) -> NSColor? { get { return unarchive(key) } set { archive(key, newValue) } } } extension DefaultsKeys { static let color = DefaultsKey<NSColor?>("color") } Defaults[.color] // => nil Defaults[.color] = NSColor.whiteColor() Defaults[.color] // => w 1.0, a 1.0 Defaults[.color]?.whiteComponent // => 1.0

（譯者注：NSColor?遵循?NSSecureCoding?協(xié)議，而該協(xié)議繼承自?NSCoding）

看上去并不十分完美，但我們僅用了幾行代碼就讓?NSUserDefaults?很好地支持了自定義類型。

結(jié)果和結(jié)論

萬事俱備，下面有請我們新的 API 登場：

// 提前定義鍵名 extension DefaultsKeys { static let username = DefaultsKey<String?>("username") static let launchCount = DefaultsKey<Int>("launchCount") static let libraries = DefaultsKey<[String]>("libraries") static let color = DefaultsKey<NSColor?>("color") } // 使用點語法來獲取 user defaults Defaults[.username] // 使用非可選的鍵來獲取默認(rèn)值而非可選值 Defaults[.launchCount] // Int, 默認(rèn)值是0 // 就地更新 value 的值 Defaults[.launchCount]++ Defaults[.volume] += 0.1 Defaults[.strings] += "… can easily be extended!" // 使用和修改數(shù)組類型 Defaults[.libraries].append("SwiftyUserDefaults") Defaults[.libraries][0] += " 2.0" // 方便地使用序列化的自定義類型 Defaults[.color] = NSColor.whiteColor() Defaults[.color]?.whiteComponent // => 1.0

Swift 中使用起來不再痛苦的靜態(tài)類型

希望你已經(jīng)看到這種靜態(tài)類型帶來的好處，我們只付出了很小的代價，包括提前定義?DefaultsKey，遵從 Swift 的類型系統(tǒng)。而作為回報，編譯器向我們獻上一份大禮：

• 編譯期檢查（鍵名，讀、寫的類型檢查）
• 鍵名（key names）自動補全
• 類型推斷——不必在末尾輸入?.string?或手動對?AnyObject?進行類型轉(zhuǎn)換
• 我們可以直接操作 user defaults 里面的值，而不需要通過中間步驟或魔法運算符
• 一致性——拋開怪異的 keys，Defaults?看上去更像是一個定義了類型的字典

這里還有一個潛在優(yōu)勢：可以自動享受到今后 Swift 的發(fā)展紅利。

真正的 Swift 的 API 也利用了靜態(tài)類型特性，這里不是要教條主義，條條大路通羅馬，肯定還有其他的最佳解決方案。但當(dāng)你決定回到 Objective-C 或 JavaScript 的編碼習(xí)慣時，重新考慮一下靜態(tài)類型所帶來的好處，還要明白一點，這種靜態(tài)類型不是你前輩所熟悉的靜態(tài)類型，Swift 豐富的類型系統(tǒng)允許你創(chuàng)造出極具表現(xiàn)力和易用的 API，而實現(xiàn)這一切的開銷卻可以忽略不計。

試試看

一如既往，我將以上所有的探索整理成了一個庫，放在?GitHub?上，如果感興趣，可以采取下面的方式引用：

# with CocoaPods: pod 'SwiftyUserDefaults' # with Carthage: github "radex/SwiftyUserDefaults"

同樣也鼓勵你去試用我改造的另一個 Swifty API（NSTimer），關(guān)于如何清晰命名請看我這篇文章?Swifty methods。

最后如果你對本文有什么好的想法或建議，請務(wù)必聯(lián)系我?Twitter?或提出?issue

轉(zhuǎn)載于:https://www.cnblogs.com/linganxiong/p/8124782.html

總結(jié)

以上是生活随笔為你收集整理的静态类型的 NSUserDefaults的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。