命名空間
對(duì)長(zhǎng)期從事objective-c語(yǔ)言開發(fā)的我們來(lái)說(shuō)，命名空間可能是一個(gè)比較陌生的名稱。
“命名空間”，簡(jiǎn)單地說(shuō)，就是不允許有相同類名的區(qū)域。從事過(guò)java或者js開發(fā)的同學(xué)可能會(huì)有經(jīng)驗(yàn)，這類語(yǔ)言的命名空間其實(shí)就是他們的目錄名，即只要在不同目錄下，就可以允許有相同的類名。
OC就比較尷尬了，它沒有命名空間一說(shuō)，也就是全局都不允許有相同的類名。那如何保證這一點(diǎn)？蘋果是建議在類名前加2-3個(gè)唯一的字符來(lái)將自己的類名與其他區(qū)分開，于是就出現(xiàn)了UIView, NSString, MBProgressHUD, CALayer, AFNetworking, SDWebImage等
swift中，蘋果終于引入了命名空間一說(shuō)，在任意類中打印一下self 會(huì)出現(xiàn)"命名空間.className"，swift中的命名空間的使用不是一個(gè)項(xiàng)目,而是需要跨項(xiàng)目,在一個(gè)項(xiàng)目中,都是一個(gè)命名空間,在同一個(gè)命名空間下,所有全局變量或者函數(shù)共享,不需要import,從swift開始,官方更多的建議大家使用pod來(lái)管理第三方框架，不然倒入一個(gè)框架到處都可以用
擴(kuò)展方法前綴
在OC中，蘋果建議在擴(kuò)展中的方法需要增加前綴，原因是防止與自帶方法或者其他庫(kù)的擴(kuò)展中方法重名，事實(shí)上也應(yīng)該這么做，因?yàn)槲覀冇星败囍b，往往這類由于重寫了方法造成的閃退，一旦xcode不能正常捕捉錯(cuò)誤，將很難排查。
swift擴(kuò)展中，同樣需要關(guān)心方法覆蓋的問題，對(duì)于原生類自帶的方法，我們可以覆蓋重復(fù)定義，并且最終調(diào)用走的是擴(kuò)展中的方法，但是擴(kuò)展中的方法不能重復(fù)定義，xcode會(huì)檢測(cè)并報(bào)錯(cuò)
自定義命名空間
綜上所述，我們自己模擬出類似“命名空間”，是個(gè)不錯(cuò)的選擇，原因如下：
1.防止擴(kuò)展中的方法或?qū)傩愿采w了原來(lái)已有的，造成無(wú)法預(yù)期的錯(cuò)誤
2.有了命名空間，我們就不需要加前綴這種影響美觀的操作，代碼可讀性更高
3.有了命名空間，開發(fā)過(guò)程中，尤其對(duì)于新人，可一眼看出方法或?qū)傩允菍儆谠愖詭У倪€是擴(kuò)展的，防止長(zhǎng)時(shí)間使用造成下意識(shí)的認(rèn)知疲勞
Swift擴(kuò)展模擬“命名空間”
首先，我們要知道swift中幾個(gè)概念：
協(xié)議：與OC中協(xié)議類似，都是定義一套遵守者需要實(shí)現(xiàn)的規(guī)則，但是與OC不同的是，在swift中我們也可以對(duì)協(xié)議進(jìn)行擴(kuò)展，最終效果是所有遵守該協(xié)議的類都會(huì)增加協(xié)議被擴(kuò)展的內(nèi)容
泛型：swift提供了“泛型”來(lái)最大程度使函數(shù)、變量、容器等靈活化，如果你在架構(gòu)一個(gè)應(yīng)用或者sdk，那么泛型可以提供最大的便利性。swift中的標(biāo)準(zhǔn)庫(kù)都是通過(guò)泛型定義的，例如Array可以塞進(jìn)Int，也可以塞進(jìn)String
泛型約束：顧名思義，就是通過(guò)泛型，來(lái)約束協(xié)議遵守者的類型
正式開始，我們的思路是通過(guò)擴(kuò)展模擬出“命名空間”，其實(shí)這不是正兒八經(jīng)的命名空間，只是期望通過(guò)一個(gè)特殊的符號(hào)，將我們自己擴(kuò)展的方法屬性等和官方的以及第三方的區(qū)分開來(lái)，類似于：
self.circleView.wm.moveToBottom()
加入circleView是一個(gè)UIView實(shí)例，這里的wm就是我們所說(shuō)的特殊符號(hào)，其實(shí)也就是一個(gè)屬性，moveToBottom就是我們自己擴(kuò)展出的方法。
看到這里，第一個(gè)問題就拋出來(lái)了，如何給circleView擴(kuò)展一個(gè)名叫wm的屬性。很多聰明火雞們就馬上會(huì)想到兩種方式，一種是擴(kuò)展UIView，增加一個(gè)屬性；另一種是使UIView遵守一個(gè)協(xié)議，通過(guò)擴(kuò)展協(xié)議來(lái)增加一個(gè)屬性。
假設(shè)，我們擴(kuò)展的屬性類型是：
public class NameSpace {
}
方法一：
extension UIView {
public var wm: NameSpace {
get {
return NameSpace()
}
}
}
方法二:
/// 命名空間協(xié)議
public protocol NameSpaceProtocol {
public var wm: NameSpace { get }
}
/// 擴(kuò)展協(xié)議
extension NameSpaceProtocol {
public var wm: NameSpace {
get {
return NameSpace()
}
}
}
/// UIView實(shí)現(xiàn)協(xié)議
extension UIView: NameSpaceProtocol {
}
我們將這兩種方式做個(gè)比較，結(jié)論還是顯而易見的，方式二的好處有：
1.我們?cè)跀U(kuò)展每個(gè)類的時(shí)候，不需要像方式一那樣都聲明一個(gè)mw的屬性，而是只要實(shí)現(xiàn)NameSpaceProtocol就可以了
2.對(duì)于子類，如果我們不希望其有這個(gè)屬性，那么方式一就無(wú)解了，方式二則可以利用泛型約束的方式，可以隨心所欲的控制
3.方式二寫法更多的采用了swift獨(dú)有的特性，風(fēng)格上更加優(yōu)雅，簡(jiǎn)單說(shuō)就是更裝*
我們?cè)诖嘶A(chǔ)上，在對(duì)NameSpace進(jìn)行擴(kuò)展，就實(shí)現(xiàn)了最終想要的效果
extension NameSpace {
public func moveToBottom() {
}
}
/// 此時(shí)，UIView已經(jīng)達(dá)到了想要的效果
let circleView = UIView()
circleView.wm.moveToBottom()
第二個(gè)問題就來(lái)了，這里我們真正擴(kuò)展的其實(shí)是NameSpace，我們這里目標(biāo)只有UIView，如果接下來(lái)還要給Date, Int, String等等擴(kuò)展，實(shí)際上都是對(duì)NameSpace擴(kuò)展，那么如果不做區(qū)分，那在其中一個(gè)類調(diào)用方法時(shí)，Xcode會(huì)提示出所有，包括其他目標(biāo)擴(kuò)展出的方法，事實(shí)上真的去調(diào)用非本目標(biāo)的方法，編譯也是不會(huì)報(bào)錯(cuò)的，但是這不是我們想要的。于是，我們引入泛型約束來(lái)做區(qū)分：
/// 命名空間
public final class NameSpace<T> {
}
/// 擴(kuò)展UIView
extension NameSpace where T == UIView {
}
這下舒服了，在使用過(guò)程中不是對(duì)UIView的擴(kuò)展不會(huì)出現(xiàn)在快捷提示。這里也做了個(gè)小優(yōu)化，就是不希望NameSpace再做它用，所以加了個(gè)final描述一下
第三個(gè)問題，circleView.wm.moveToBottom()這個(gè)方法，如果moveToBottom方法中需要訪問circleView的方法或?qū)傩栽趺凑?？我們知道我們?shí)際上擴(kuò)展的是NameSpace類，所以我們需要在NameSpace中記錄下來(lái)原來(lái)的對(duì)象就完事了：
/// 命名空間協(xié)議
public protocol NameSpaceProtocol {
associatedtype TargetType
/// 實(shí)例變量及方法命名空間
var wm: NameSpace<TargetType> { get }
}
/// 命名空間
public final class NameSpace<T> {
internal var base: T
init(_ base: T) {
self.base = base
}
}
/// 擴(kuò)展協(xié)議
extension NameSpaceProtocol {
public var wm: NameSpace<Self> {
get {
return NameSpace<Self>(self)
}
}
}
/// 在擴(kuò)展過(guò)程中通過(guò)self.base訪問原來(lái)對(duì)象
extension NameSpace where T == UIView {
public func moveToBottom() {
print("my x is \(self.base.frame.origin.x)")
}
}
寫到這里，已經(jīng)讓大部分火雞們滿足了需求，實(shí)際上網(wǎng)上大多數(shù)資料也就到此為止了，但是仍然有部分不滿意，因?yàn)槲覀円恢弊龅亩际菍?duì)實(shí)例屬性或者是方法做擴(kuò)展，如果是類屬性或者方法，類似于UIColor.wm.color(hexString)這中，其實(shí)也簡(jiǎn)單，過(guò)程不過(guò)多贅述，直接貼上：
/// 命名空間協(xié)議
public protocol NameSpaceProtocol {
associatedtype TargetType
/// 實(shí)例變量及方法命名空間
var wm: NameSpace<TargetType> { get }
/// 類變量及方法命名空間
static var wm: NameSpace<TargetType>.Type { get }
}
/// 命名空間
public final class NameSpace<T> {
internal var base: T
internal var BASE: Self.Type
init(_ base: T) {
self.base = base
self.BASE = Self.self
}
}
/// 擴(kuò)展協(xié)議
extension NameSpaceProtocol {
public var wm: NameSpace<Self> {
get {
return NameSpace<Self>(self)
}
}
public static var wm: NameSpace<Self>.Type {
get {
return NameSpace<Self>.self
}
}
}
/// 例子：擴(kuò)展UIImage
extension UIImage: NameSpaceProtocol {}
extension NameSpace where T == UIImage {
/// 根據(jù)顏色生成圖片, 類方法
public class func image(color: UIColor?, size: CGSize = CGSize(width: 1, height: 1)) -> UIImage {
UIGraphicsBeginImageContextWithOptions(size, false, UIScreen.main.scale);
if let color = color, let currentContext = UIGraphicsGetCurrentContext() {
let fillRect = CGRect(x: 0, y: 0, width: size.width, height: size.height);
currentContext.setFillColor(color.cgColor)
currentContext.fill(fillRect)
let colorImage = UIGraphicsGetImageFromCurrentImageContext()
UIGraphicsEndImageContext()
return colorImage ?? UIImage()
}
return UIImage()
}
/// 寬度，實(shí)例屬性
public var width: CGFloat {
return self.base.size.width
}
}
/// 實(shí)際使用
let image = UIImage.wm.image(color: .red, size: CGSize(width: 100, height: 200))
print("the image width is\(image.wm.width)")
注意一：在擴(kuò)展NameSpace之前，我們需要將目標(biāo)實(shí)現(xiàn)一下NameSpaceProtocol協(xié)議，但是實(shí)際開發(fā)過(guò)程中你會(huì)發(fā)現(xiàn)有些會(huì)報(bào)警告說(shuō)已經(jīng)實(shí)現(xiàn)過(guò)了，不必驚慌，那是因?yàn)楦割悓?shí)現(xiàn)過(guò)，子類就不必實(shí)現(xiàn)了，比如可以將NSObject實(shí)現(xiàn)NameSpaceProtocol協(xié)議，之后UIView等類就不用再寫這一步驟了
注意二：也許有火雞想利用runtime擴(kuò)展屬性，請(qǐng)注意，在擴(kuò)展NameSpace時(shí)，屬性runtime方式添加時(shí)，務(wù)必添加到self.base中：
/// 響應(yīng)對(duì)象
private var target: ButtonActionTarget? {
get {
return objc_getAssociatedObject(self.base, "buttonActionTarget") as? ButtonActionTarget
}
set {
if let newValue = newValue {
objc_setAssociatedObject(self.base, "buttonActionTarget", newValue, .OBJC_ASSOCIATION_RETAIN_NONATOMIC)
}
}
}
如果你添加到self，會(huì)發(fā)現(xiàn)并不生效，也就是get的時(shí)候一直為nil，這是因?yàn)楸旧鞱ameSpace的作用域并不大，因?yàn)槲覀冊(cè)跀U(kuò)展NameSpaceProtocol時(shí)只是臨時(shí)初始化了NameSpace，并沒有引用保存。
然后關(guān)于Self, .self, .Type的理解，大家可以執(zhí)行查詢，不過(guò)簡(jiǎn)單來(lái)說(shuō)：
Self：用在協(xié)議中，代表的是協(xié)議自身或者實(shí)現(xiàn)者或者子類的類型
.self：用在哪代表的就是什么的自身，比如用在實(shí)例后面就是實(shí)例本身，類型后面就是類型本身
.Type：獲取調(diào)用者的類型
最后再次聲明下為什么我們要實(shí)現(xiàn)這個(gè)命名空間的效果：
1.在調(diào)用的時(shí)候，Xcode的快捷提示中不會(huì)顯示目標(biāo)的自帶方法，不會(huì)產(chǎn)生混淆，對(duì)新人來(lái)說(shuō)非常友好
2.加了一層命名空間，有效避免覆蓋重寫的風(fēng)險(xiǎn)
3.更加優(yōu)雅，許多知名的第三方也都這么做了，比如RxSwift
