命名UITableView的间距和画线的位置

（本文最初是为我的博客 vojtastavik.com撰写的 ）

Objective-C是我专业学习和使用的第一门编程语言。 使用ObjC时需要了解的第一件事是缺少名称空间。 整个Objective-C运行时的行为就像一个名称空间。 为了防止名称冲突，Objective-C使用名称前缀。 您只需为所有类的名称加上前缀就可以创建自己的伪命名空间。 这就是为什么我们要使用UI View， NS Object和MK MapView之类的名称的原因。

Swift具有模块定义的名称空间，因此不再需要名称前缀。 我不得不说我想念他们。 将您的姓名缩写作为班级名称的一部分，会带来一种奇怪的满足感。

让我们做一点思想实验。 UITableView是iOS开发的重点之一。 它是iOS 2.0中引入的，它是我们仍在积极使用的最古老的API之一。 如果UITableView API名称是在2017年引入的，仅支持Swift，那么UITableView API名称会是什么样？ 让我们玩一下命名空间。

由于UIKit拥有自己的命名空间，因此我们可以简单地将Table用作表视图相关类型的“基础”命名空间。 如果模块中已经有一个名为Table的类型，则需要将UIKit版本称为UIKit.Table 。 但是，在大多数情况下，使用简单的Table完成工作。

在操场上进行模拟非常简单：

这是在代码中使用UITableView 2017 Swift专用版本的方式：

iOS世界中最著名的两个协议呢？ UITableViewDataSource和UITableViewDelegate呢？ 让我们也给他们一个合适的名称空间：

我们不要在这里停下来。 我们可以命名空间还有很多！

您可能会明白…这里的真正问题是：

这就是我们想要的吗？

对所有事物进行命名空间是一个好主意吗？ 像这样构造类型非常好。 层次结构清晰可见，全局命名空间的“污染程度”较小。 简短的名字也对新来者不那么害怕。

让我们也考虑一下缺点。 关于类型的推理可能更加复杂，尤其是在名称冲突的情况下。 根据上下文的不同， Table有时可以表示UIKit.Table ，有时不可以。 嵌套类型的自动补全当前仅在一个名称空间“级别”中起作用，因此您目前无法对嵌套类型执行以下操作：

在哪里划界线？

撰写本文的主要灵感来自我正在从事的项目。 我意识到，即使使用Swift强大的命名空间功能可能会更好，我还是倾向于选择与Objective-C相似的名称作为类型。

我对哪种方法更好没有很坚决的看法，“在命名空间中过多使用”这一行也没有。 我很高兴听到有关此主题的更多意见！ 随时在下面发表评论。

另请参见本博客文章中的示例代码和要点。