Objective-C 相当于 Java 包吗？

Java 包的 Objective-C 等价物是什么？你如何用 Objective-C 来分组和组织你的课程？

问题 1：Objective-C 相当于 Java 包吗？

Objective-C 没有与 Java 包或 C++ 命名空间等效的东西。部分原因是 Objective-C 最初是 C 之上的一个非常薄的运行时层，并且可以轻松地将对象添加到 C 中。对我们来说不幸的是，命名冲突是我们在使用 Objective-C 时必须处理的问题。你赢得了一些，你失去了一些......

一个小小的澄清（尽管这并不能带来太多安慰）是 Objective-C 实际上有两个平面命名空间——一个用于类，另一个用于协议（如 Java 的接口）。这并不能解决任何类命名冲突，但它确实意味着您可以拥有同名的协议和类（例如 http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Protocols/NSObject_Protocol/ and NSObject http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSObject_Class/），后者通常采用（“实现”）前者。此功能可以防止 Java 中“Foo / FooImpl”模式泛滥，但遗憾的是对解决类冲突没有帮助。

问题 2：如何命名和组织 Objective-C 课程？

Naming

以下规则是主观的，但它们是命名 Objective-C 类的不错的指南。

1. 如果您的代码无法由其他代码运行（它不是框架、插件等，而是最终用户应用程序或工具），您只需避免与链接的代码发生冲突即可。通常，这意味着只要您使用的框架/插件/捆绑包具有正确的命名空间，您就可以完全没有前缀。
2. 如果您正在开发“组件化”代码（例如框架、插件等），您应该选择一个前缀（希望是唯一的）并在可见的地方记录您对它的使用，以便其他人知道避免潜在的冲突。例如，CocoaDev 维基“注册表” http://www.cocoadev.com/index.pl?ChooseYourOwnPrefix是一个事实上的公共论坛，用于在前缀上调用“dibs”。但是，如果您的代码类似于公司内部框架，则您可以使用其他人已经使用的前缀，只要您不使用带有该前缀的任何内容即可。

组织

不幸的是，许多 Cocoa 开发人员都忽略了在磁盘上组织源文件的事情。当您在 Xcode 中创建新文件时，默认位置是项目目录，就在您的项目文件旁边等。就我个人而言，我将应用程序源放在source/、测试代码（OCUnit等）中test/，所有资源（NIB/XIB 文件、Info.plist、图像等）资源/， 等等。如果您正在开发一个复杂的项目，那么根据功能将源代码分组到目录层次结构中也可能是一个很好的解决方案。无论如何，组织良好的项目目录可以让您更轻松地找到所需内容。

Xcode 实际上并不关心你的文件所在的位置。项目侧边栏中的组织完全独立于磁盘位置 - 它是逻辑（而非物理）分组。您可以在侧栏中以您喜欢的方式进行组织，而不会影响磁盘位置，当您的源存储在版本控制中时，这很好。另一方面，如果您在磁盘上移动文件，则修补 Xcode 引用是手动且乏味的，但可以完成。最简单的方法是从一开始就创建组织，并在文件所属的目录中创建文件。

我的想法

虽然拥有包/命名空间机制可能很好，但不要屏息以待它的发生。阶级冲突在实践中很少见，并且当它们发生时通常是非常明显的。命名空间实际上是 Objective-C 中非问题的解决方案。 （此外，添加命名空间将消除对前缀等解决方法的需要，但可能会在方法调用等方面引入更多的复杂性。）

更微妙和狡猾的错误来自方法冲突当添加和/或重写方法时，不仅是子类，而且是类别，这可能会导致严重的错误，因为类别的加载顺序是未定义的（不确定的）。实现类别是 Objective-C 最锋利的优势之一，只有当您知道自己在做什么时才应该尝试，特别是对于第三方代码，并且尤其用于 Cocoa 框架类。