當UIColor遇上Swift

我為這篇文章制作了一個demo，已經上傳到我的GitHub： KTColor ，如果覺得有幫助還望給個star以示支持。

UIColor 提供了幾個默認的顏色，要想創建除此以外的顏色，一般是通過RGB和alpha值創建(十六進制的顏色其實也是被轉換成RGB)。在 Objective-C 中，這可以通過自定義宏來完成，在 Swift 中，我們可以利用 Swift 的一些語法特性來簡化創建 UIColor 對象的過程。我想，最理想的解決方案應該是這樣：

override func viewDidLoad() {
super.viewDidLoad()
self.view.backgroundColor = "224, 222, 255"
}

變通方案

然而很不幸的是，在目前的 Swift 版本(2.1)中，這種寫法暫時無法實現。據我所知，Swift3.0 也不支持這種寫法，原因會在稍后分析。目前，我們可以使用兩種變通方案：

self.view.backgroundColor = "224, 222, 255".ktColor    // 方案1
self.view.backgroundColor = "224, 222, 255" as KtColor    // 方案2

兩者寫法類似，但實現原理實際上完全不同。第一種方案是通過拓展 String 類型實現的，第二種方案則是通過繼承 UIColor 實現。

方案1有更好的代碼提示，但它對 String 類型作了修改，我的demo中有完整的實現，它支持以下輸入：

self.view.backgroundColor = "224, 222, 255, 0.5".ktcolor // 這個是完整版
self.view.backgroundColor = "224, 222, 255".ktcolor // alpha值默認為1
self.view.backgroundColor = "224,222,255".ktcolor // 可以用逗號分割
self.view.backgroundColor = "224 222 255".ktcolor // 可以用空格分割
self.view.backgroundColor = "#DC143C".ktcolor  // 可以使用16進制數字
self.view.backgroundColor = "#dc143c".ktcolor  // 字母可以小寫
self.view.backgroundColor = "SkyBlue".ktcolor  // 可以直接使用顏色的英文名字

雖然方案2不會對現有代碼做修改，但它并不適用于所有系統類型，比如 NSDate 或 NSURL 類型，出于這種考慮，demo中僅實現了關鍵邏輯。但這種實現方法最接近于理想的解決方案，一旦時機合適，我們就可以去掉丑陋的 as KtColor。

拓展字符串

第一種方案通過拓展 String 類型實現，它添加了一個 ktcolor 計算屬性，主要涉及到字符串的分割與處理，還有一些容錯、判斷等，這些就不是本文的重點了，如果有興趣，讀者可以通過閱讀源碼獲得更加深入的了解。

這種方案的好處在于它還適用于 NSDate、NSURL等類型。比如，下面的代碼可以通過類似的技術實現：

let date = "2016-02-17 24:00:00".ktdate
let url = "http://bestswifter.com".kturl

不過，方案一選擇的技術注定了它沒有再簡化的空間了。如果不能顯著的減少代碼量，它就沒有理由取代原生的方案。

字符串字面量

方案二和理想方案采用的都是同一個思路：“利用字符串字面量創建對象”。

簡單來說，我們要做的只是為 UIColor 類型添加如下的拓展：

extension UIColor: StringLiteralConvertible {
public init(stringLiteral value: String) {
//這里的數字是隨便寫的，實際上需要解析字符串
self.init(red: 0.5, green: 0.8, blue: 0.25, alpha: 1)
}
public init(extendedGraphemeClusterLiteral value: String) {
self.init(stringLiteral: value)
}
public init(unicodeScalarLiteral value: String) {
self.init(stringLiteral: value)
}
}

不過你會收到這樣的報錯：

Initializer requirement 'init(stringLiteral:)' can only be satisfied by a required initializer in the definition of non-final class 'UIColor'

Xcode 的報錯有時候不愛說人話，其實這句話的意思是說，'UIColor' 不是一個標記為 final 的類，也就是它還可以被繼承。因此 init(stringLiteral:) 函數需要被標記為 required 以確保所有子類都實現了這個函數。否則，如果有子類沒有實現它，那么子類就不滿足 StringLiteralConvertible 協議。

好吧，我們聽從 Xcode 的指示，把每個函數都標記為 required，新的問題又出現了：

'required' initializer must be declared directly in class 'UIColor' (not in an extension)

這是因為 Swift 不允許在類型拓展中聲明 required 函數。required 函數必須被直接聲明在類的內部。

這就導致了一個死循環，因此目前理想方案無法實現，除非未來 Swift 允許在拓展中聲明required 函數。

繼承

方案二采用了變通的解決方案。首先創建一個 UIColor 的子類，我們可以讓這個子類實現 StringLiteralConvertible 協議，然后將子類對象賦值給父類：

class KtColor: UIColor, StringLiteralConvertible {
required init(stringLiteral value: String) {
//這里的數字是隨便寫的，實際上需要解析字符串
super.init(red: 0.5, green: 0.8, blue: 0.25, alpha: 1)
}
required convenience init(extendedGraphemeClusterLiteral value: String) {
self.init(stringLiteral: value)
}
required convenience init(unicodeScalarLiteral value: String) {
self.init(stringLiteral: value)
}
required init?(coder aDecoder: NSCoder) {
fatalError("init(coder:) has not been implemented")
}
required convenience init(colorLiteralRed red: Float, green: Float, blue: Float, alpha: Float) {
self.init(colorLiteralRed: red, green: green, blue: blue, alpha: alpha)
}
}
override func viewDidLoad() {
super.viewDidLoad()
self.view.backgroundColor = "224, 222, 255" as KtColor
}

這種方法有一個顯而易見的好處，一旦 Swift 做出了修改，比如允許在拓展中聲明required 函數，我們只需要微小的改動就可以實現理想方案。

局限性

繼承 UIKit 中的類并不總是一種可行的方法。比如 NSDate 類其實是一個類簇，官網對它有如下解釋：

The major reason for subclassing NSDate is to create a class with convenience methods for working with a particular calendrical system. But you could also require a custom NSDate class for other reasons, such as to get a date and time value that provides a finer temporal granularity. If you want to subclass NSDate to obtain behavior different than that provided by the private or public subclasses, you must do these things:

列出了一大串你根本不想去做的事，省略一萬字。。。。。。

簡單來說，如果你想繼承 NSDate，就必須重新實現它。

除了類簇，像 NSURL 這樣，指定構造函數是可失敗構造函數的類也無法使用繼承：

class KtURL : NSURL, StringLiteralConvertible {
required init(stringLiteral value: StringLiteralType) {
super.init(string: value, relativeToURL: nil)
}
// 其他的函數略
}

StringLiteralConvertible協議中定義的構造函數是不可失敗構造函數，它不會返回 nil。在它的內部調用了父類，也就是 NSURL 的 init(string:relativetoURL:)，這是可失敗構造函數。Swift不允許出現這種情況，否則如果傳入的參數 value 不合法，你會得到 nil么，如果不是 nil 那么會得到什么？

總結

完全使用字符串字面量創建已有類的實例變量在目前是無法實現的，一種想法類似但是存在局限性的方法是使用子類。或者也可以拓展 String類型，但如果相比于原生實現，不能較大幅度的減少代碼量，我不建議這么做。

參考資料：

https://devforums.apple.com/message/1057368#1057368 ：這個好像是喵神提的問題。

Swift: Simple, Safe, Inflexible

文／bestswifter（簡書作者）

原文鏈接： http://www.jianshu.com/p/f2173235cde8

 

來自： http://www.cocoachina.com/swift/20160523/16384.html