定义
命名空间：是用来组织和重用代码的。如同名字一样的意思，NameSpace（名字空间），之所以出来这样一个东西，是因为人类可用的单词数太少，并且不同的人写的程序不可能所有的变量都没有重名现象，对于库来说，这个问题尤其严重，如果两个人写的库文件中出现同名的变量或函数(不可避免)，使用起来就有问题了。为了解决这个问题，引入了名字空间这个概念，通过使用 namespace xxx；你所使用的库函数或变量就是在该名字空间中定义的，这样一来就不会引起不必要的冲突了。

当在对系统库做 extension 的时候，就会涉及到一个命名冲突的问题。Objective-C 时代的通行解决办法是在扩展方法名字的最前面加上 XXX_ 形式的前缀。这种形式不但解决了命名冲突的问题，而且增强了代码可读性。在前缀形式的扩展使用了一段时间之后，大家渐渐觉得前缀形式的 Objective-C 风格不再适合 Swift。在命名方式上，社区掀起了一股 Swifty 化的风潮。WWDC 2016 的 Session 403 Swift API Design Guidelines 中详细阐述了 Swifty 风格的命名规则，而 Swift 3 的大量 API 的改动，也是按照这种风格进行的演进。很多开源的 Swift 陆陆续续在接下来的版本中，抛弃了之前的前缀命名形式，改用了 namespace 形式的命名。比如 Kingfisher 的 kf_ => kf.，SnapKit 的 snp_ => snp.。

image.png
image.png

Swift 命名空间形式扩展的实现

#if os(macOS)
import AppKit
public typealias Image = NSImage
public typealias View = NSView
public typealias Color = NSColor
public typealias ImageView = NSImageView
public typealias Button = NSButton
#else
import UIKit
public typealias Image = UIImage
public typealias Color = UIColor
#if !os(watchOS)
public typealias ImageView = UIImageView
public typealias View = UIView
public typealias Button = UIButton
#else
import WatchKit
#endif
#endif

// MARK: -
// MARK: - MG
public struct MGNameSpaceWrappable<Base>:MGTypeWrapperProtocol {
    public let base: Base
    init(_ base: Base) {
        self.base = base
    }
}

public protocol MGTypeWrapperProtocol {

}

extension MGTypeWrapperProtocol {
    public var mg: MGNameSpaceWrappable<Self> {
        get {
            return MGNameSpaceWrappable(self)
        }
        set {
            
        }
    }
}

// MARK: -
// MARK: - LYM
public protocol LYMNamespacePotocol {
    associatedtype WrapperType
    var lym: WrapperType { get }
    static var lym: WrapperType.Type { get }
}

public extension LYMNamespacePotocol {
    var lym:  LYMNamespaceWrapper<Self> {
        return  LYMNamespaceWrapper(value: self)
    }

    static var lym:  LYMNamespaceWrapper<Self>.Type {
        return  LYMNamespaceWrapper.self
    }
}

public protocol  LYMTypeWrapperProtocol {
    associatedtype WrappedType
    var wrappedValue: WrappedType { get }
    init(value: WrappedType)
}

public struct  LYMNamespaceWrapper<T>:  LYMTypeWrapperProtocol {
    public let wrappedValue: T
    public init(value: T) {
        self.wrappedValue = value
    }
}

如何调用

使用截图
调用

---

分析一下MG为前缀的命名空间流程吧

• 1、首先定义一个泛型结构体(或者类)MGNameSpaceWrappable，使用泛型Base
• 2、然后定义一个协议MGTypeWrapperProtocol.
• 3、然后对MGTypeWrapperProtocol协议扩展，并实现相关命名空间的对象(:MGNameSpaceWrappable<Self>)的getter和setter方法（如代码中的localized方法）。
• 4、最后指定某个类遵循MGNameSpaceWrappable。只有遵循MGNameSpaceWrappable的类才拥有该命名空间。
  extension UIView: MGNameSpaceWrappable { }

extension MGNameSpaceWrappable where Base: View {
    func sss() {
        print("ssss")
    }
}

let btn = UIButton()
btn.mg.sss()

<font color="#dd0000">在对 MGTypeWrapperProtocol 这个协议做 extension 时， where 后面的 WrappedType 约束可以使用 <font size="5" color="#11aa00">== </font>或者 <font size="5" color="#00dd00">:</font>，两者是有区别的。<font color="#0000dd">如果扩展的是值类型，比如 String，Date等</font> ，就必须使用 <font size="5" color="#11aa00">==</font>，<font color="#0000dd">如果扩展的是类，则两者都可以使用</font>，区别是如果使用 <font size="5" color="#11aa00"> ==</font> 来约束，则扩展方法只对本类生效，子类无法使用。如果想要在子类也使用扩展方法，则使用 <font size="5" color="#11aa00">:</font> 来约束。

举个例子：UIView遵守协议 <font color="#11aa00">==</font> ，UIButton去掉用sss()方法，会报错

image.png

但是觉得遵守<font color="#dd0000">MGNameSpaceWrappable</font> 并不是很好理解，一般都是遵守协议，对协议进行扩展，所以有了lym的命名空间。相比于mg的命名空间，多封装了<font color="#dd0000">LYMTypeWrapperProtocol</font> 这个协议。遵守<font color="#dd0000">LYMTypeWrapperProtocol</font>，然后对<font color="#dd0000">LYMTypeWrapperProtocol</font>协议做扩展即可

---

慕课网址

关注我

慕课网

---

---

参考SnapKit

参考Kingfisher