==命名空间== 是一种改进代码结构的强大功能。尽管在Swift中受到限制，但它可以通过使用嵌套类型来进行弥补。让我们看看默认情况下Swift中的命名空间是如何工作的，以及如何对其进行模拟。
定义命名空间
==命名空间== 是程序的命名区域，用于对变量、类型和方法进行分组。命名空间有以下好处：
- 允许通过将元素（否则将具有全局作用域）组织到局部作用域来改进代码结构
- 防止名称冲突
- 提供封装
==Swift中命名空间是啥情况？== 命名空间在Swift中是隐含的，这意味着所有类型、变量（等）都由模块自动确定作用域，而模块又对应于Xcode目标（Xcode target）。
大多数情况下，访问外部作用域类型不需要模块前缀：
let zeroOrOne = Int.random(in: 0...1)
print(zeroOrOne) // Prints 0 or 1
尽管 Int 在外部声明，但作用域却是自动计算的。
==什么是名称冲突？== 在名称冲突的情况下，本地类型会影响外部类型：
struct Int {}
let zeroOrOne = Int.random(in: 0...1) // error: type 'Int' has no member 'random'
本地类型 Int 未声明 random(in:) 方法，因此出现错误。要解决歧义，必须显式指定命名空间。Swift 是所有基础类型（foundation types）和原始类型（primitives）的命名空间，包括 Int。Article_Namespacing 就是当前Xcode目标（Xcode target）的命名空间：
struct Int {}
let zeroOrOne = Swift.Int.random(in: 0...1)
let myInt = Article_Namespacing.Int.init()
==什么是外部名称冲突？== 另一种可能的情况是来自两个框架的名称冲突。比方说，FrameworkA 和 FrameworkB 都声明自己的 Int 类型，如下所示：
name-collision.png
这种歧义（编译器）不会自动解决。
import FrameworkA
import FrameworkB
print(Int.init()) // Oops, error: Ambiguous use of 'init()'
可以通过添加命名空间来解决此问题：
import FrameworkA
import FrameworkB
print(FrameworkA.Int.init()) // Prints: FrameworkA
print(FrameworkB.Int.init()) // Prints: FrameworkB
Import 语句有多个鲜为人知的特性，值得讨论。
Import 语句语法
==按子模块导入== 模块具有层级结构，可以由子模块组成。可以将导入的命名空间限制为子模块：
import UIKit.NSAttributedString
func foo() -> UIView { // All good
return UIView()
}
想知道为什么 UIView 仍然可以访问？UIKit.NSAttributeString 导入整个 UIKit，另外还导入 Foundation。
==按符号导入== 当前作用域中只有导入的符号（而不是声明它的模块）可用：
import class UIKit.NSAttributedString
func foo() -> UIView { // error: Use of undeclared type 'UIView'
return UIView()
}
注意这里的 class 关键字；swift 提供了其他可能的选项以及完整的导入语句语法 available at swift。
命名空间技术
隐式的每个模块命名空间通常不足以表示复杂的代码结构。解决方案就是通过嵌套枚举创建伪命名空间。
==为什么要枚举？== 与结构体不同，枚举没有合成（synthesized）的初始化器（ initializers）；与类不同，它们不允许子类化，这使它们成为模拟命名空间的完美候选对象。让我们看看实际例子。
==更好地组织常量== 指定常量的几种方式：全局变量、属性、配置文件。命名空间以可读性、可理解性和一致性的方式对常量进行分组，而不会污染外部作用域。以下示例将视图控制器的常量分组到命名空间中：
class ItemListViewController {
...
}
extension ItemListViewController {
enum Constants {
static let itemsPerPage = 7
static let headerHeight: CGFloat = 60
}
}
如果放入全局作用域，常量将如何命名？我想，这些已经足够接近（close enough）了：
let itemListViewControllerItemsPerPage = 7
let itemListViewControllerHeaderHeight: CGFloat = 60
这些名称看起来一模一样，很难阅读，而且容易拼写错误。没有比这更麻烦的名字了。对比下面：
ItemListViewController.Constants.itemsPerPage
ItemListViewController.Constants.headerHeight
==工厂和工厂方法== 对象的创建通常包含复杂的映射、验证和特殊情况处理。命名空间工厂和工厂方法提供了一种简便的方法，可以使创建和映射逻辑与原始类型保持接近，而不会污染外部作用域：
struct Item {
...
}
extension Item {
enum Factory {
static func make(from anotherItem: AnotherItem) -> Item {
// Complex computations to map AnotherItem into Item
return Item(...)
}
}
}
// Usage:
let anotherItem = AnotherItem()
let item = Item.Factory.make(from: anotherItem)
==按使用区域分组== 网络层通常需要用于请求和响应的专用模型，而这些模型在其他任何地方都不会使用，因此可以很好地分组到命名空间中：
enum API {
enum Request {
struct UpdateItem {
let id: Int
let title: String
let description: String
}
}
enum Response {
struct ItemList {
let items: [Item]
let page: Int
let pageSize: Int
}
}
}
此类代码是自文档化（self-documented）的；全局作用域没有被请求名称污染，因为它在没有上下文的情况下是不明确的。
总结
好的代码结构的重要性不可低估。命名空间通过将相关元素分组到本地作用域并使代码自文档化（self-documented）来改进代码结构。
Swift 对名称空间的内置支持有限，但可以通过使用嵌套类型作为伪命名空间进行弥补。
如果寻找更多的方法来提高代码质量，那么 article on Swift Code Style 可能会特别有意思。
（==完==）
ps: 以上仅代表个人理解，如果翻译的不对，请不惜指正，同时感谢原文作者！-
网友评论