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的接口).这并不能解决任何类命名冲突,但它确实意味着你可以拥有一个具有相同名称的协议和类(如和NSObject),后者通常采用("实现")前者.此功能可以防止Java中的"Foo/FooImpl"模式泛滥,但遗憾的是无法解决类冲突.

问题2:如何[命名]和组织Objective-C类？

命名

以下规则是主观的,但它们是命名Objective-C类的合适指南.

如果您的代码不能由其他代码运行(它不是框架,插件等,而是最终用户应用程序或工具),您只需要避免与链接的代码发生冲突.通常,这意味着您可以完全不使用前缀,只要您使用的框架/插件/包具有适当的名称空间即可.

如果你正在开发"组件化"代码(比如框架,插件等),你应该选择一个前缀(希望是一个独特的前缀)并记录你在某个地方可见的使用,以便其他人知道以避免潜在的冲突.例如,CocoaDev wiki"注册表"是一个事实上的公共论坛,用于在前缀上调用"dibs".但是,如果您的代码类似于公司内部框架,那么您可以使用其他人已经执行过的前缀,只要您不使用具有该前缀的任何内容即可.

组织

在磁盘上组织源文件是许多Cocoa开发人员遗憾的事情.当你在Xcode中创建一个新文件时,默认位置是项目目录,就在项目文件旁边,等等.我个人将源应用程序源放在test /中,测试代码(OCUnit等)在test /中,所有资源(资源/中的 NIB/XIB文件,Info.plist,图像等),依此类推.如果您正在开发一个复杂的项目,那么基于功能对目录层次结构中的源代码进行分组也是一个很好的解决方案.无论如何,组织良好的项目目录可以更容易地找到您需要的内容.

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

我的看法

虽然拥有一个包/命名空间机制可能会很好,但不要屏住呼吸它.阶级冲突在实践中是非常罕见的,并且在它们发生时通常是明显的.命名空间实际上是Objective-C中非问题的解决方案.(此外,添加名称空间可以避免像前缀这样的变通方法的需要,但可能会在方法调用中引入更多的复杂性等)

当方法被添加和/或覆盖时,方法冲突会产生更微妙和狡猾的错误,不仅是子类,还有类别,这可能导致令人讨厌的错误,因为类别的加载顺序是未定义的(非确定性).实现类别是Objective-C最尖锐的边缘之一,只有当您知道自己在做什么时才应该尝试,特别是对于第三方代码,尤其是Cocoa框架类.