用列舉簡化登入操作

發表於2016-07-30

今天的內容翻譯自Simplifying Login with Swift Enums,隱隱約約的記得好像有人翻譯過這篇內容,我本來對這篇內容不是很感興趣,但無意中發現了另外一篇博文指出:《Simplifying Login with Swift Enums》這麼做並不好,所以我的興趣就來了,我準備把兩篇內容都整理一下,今天先發這一篇。首先要推薦大家看原文,我這裡並沒有逐句的對照翻譯,我是按照自己的理解重新把內容整理了一遍。如果有出現不正確的地方歡迎大家留言給我。

原作者David East根據自己的經驗得出一個結論:一款app在登入操作上,如果想獲得使用者的信任和好評,那麼需要為使用者提供選擇,提供多種登陸方式。David East認為swift的列舉可以有效的對登入邏輯進行抽象,從而令我們能夠保持view controllers的乾淨簡潔。我自己確認為這篇內容做為enum的基本介紹是比較合適的。

使用列舉定義社交賬號登入

很多語言的列舉只是出於型別安全的考慮而把普通型別打個包而已,而swift中的列舉則是一個實實在在的 first-class,列舉中每一個case都是一個fully-fledged value,例如:Facebook 的型別就是LoginProvider。

列舉的Raw Values

我們可以給列舉的每一個case儲存一個值,我們把這種值稱作列舉的Raw Values。

對於Raw Values我們應該關注幾件事情:

  • Raw Values要求列舉的定義是有明確的返回型別,我們這裡是 String
  • 列舉的每個case的型別必須是一致的
  • 我們可以通過rawValue來初始化一個列舉,引數名稱就是rawValue

通過定義的rawValue “email”,我們可以獲得一個 Email,這個確實很方便。

Associated Values

rawValue實際上是給列舉的每個case做了一個常量的預設值,那我們可不可以給每個case繫結一個變數值呢?這樣的話我們就可以非常方便的給以列舉根據特定情況繫結不同的值了。幸運的是,swift確實提供這個能力:Associated Values

關於Associated Values我們可以關注幾件事情:

  • 每個case的型別可以不同,各自根據各自的需要使用型別
  • 列舉的定義上面沒有返回值了
  • Associated Values可以是任意型別

我們可以定義一個user型別,然後作為列舉的Associated Values。

有了這樣的定義之後,我們就可以建立一個Email列舉了.

在Associated Values特性的幫助下,列舉可以“滲透到”各種問題的解決方案中去,而不會因為關聯型別問題而被拒之門外。

case where

原作者說:正是因為有Associated Values特性的存在,才顯得case where特別的甜。

case let 首先對Email進行了值繫結(把user物件抽出來),然後使用使用where關鍵字引入的條件表示式,對邏輯進行了一步處理。switch與列舉的配合確實相當完美(和Tuples也類似)。

Functions

說case where還只是一個鋪墊,畢竟我們是在這裡讚美列舉嗎,switch再好也不是列舉的內容啊。無需感到遺憾,列舉內可以定義function,可以整合所有你需要的內容。

我們在列舉中定義方法以後,我們的登入方案就顯得很完整了,而且非常的簡潔。

關於這部分內容並沒有結束,因為反對意見還沒有出場,如果感興趣可以關注我的下一篇內容:這樣做並不怎麼好。

原作者非常看重列舉能夠把不同的內容整合在一起並體現統一的型別。如果沒有列舉的幫助,在統一各種不同的登入SDK上面,我們確實需要在協議和實現上面花不少功夫,而且列舉提供非常棒的特性,能夠進一步抽象業務邏輯,總之swift的列舉是非常值得點讚的

相關文章