Java包的Objective-C等价物？答案

【问题标题】：Objective-C equivalent of Java packages?Java包的Objective-C等价物？
【发布时间】：2010-11-03 07:06:54
【问题描述】：

什么是 Java 包的 Objective-C 等价物？您如何在 Objective-C 中对课程进行分组和组织？

【问题讨论】：

将“Java”重新标记为“Cocoa”，这样 Java 人就不会对什么是真正的 Objective-C 问题感到困惑/愤怒。 :-)
好的，但是这个问题和 Cocoa 有更多关系吗？
本题与cocoa无关
你说得有道理。尽管 Objective-C 与 Cocoa 紧密相关，但这个问题专门针对语言而不是 Cocoa 框架。所以我要删除 Cocoa 标记。

【解决方案1】：

这样的东西（在目录中）怎么样？

 #define PruebaPaquete ar_com_oxenstudio_paq1_PruebaPaquete
@interface ar_com_oxenstudio_paq1_PruebaPaquete : NSObject {

并像这样导入它：

 #import "ar/com/oxenstudio/paq1/PruebaPaquete.h"
 PruebaPaquete *p = [[PruebaPaquete alloc] init];

当你有名字冲突时：

 #import "ar/com/oxenstudio/paq1/PruebaPaquete.h"
 #import "ar/com/oxenstudio/paq2/PruebaPaquete.h"


ar_com_oxenstudio_paq1_PruebaPaquete *p = [[ar_com_oxenstudio_paq1_PruebaPaquete alloc] init];
ar_com_oxenstudio_paq2_PruebaPaquete *p2 = [[ar_com_oxenstudio_paq2_PruebaPaquete alloc] init];

【讨论】：

【解决方案2】：

好吧，我认为这里的所有其他答案似乎都集中在命名冲突上，但至少错过了一个重要功能，即 java 包提供的 包私有访问控制。

当我设计一个类时，我经常发现我只是想要一些特定的类来调用它的方法，b/c 他们一起工作来完成一个任务，但我不想要所有其他的不相关的类来调用这些方法。这就是java包访问控制派上用场的地方，所以我可以将相关的类分组到一个包中，并使这些方法封装私有访问控制。但是在目标 c 中没有办法做到这一点。

如果没有包私有访问控制，我发现很难避免人们编写这样的代码，[[[[[a m1] m2] m3] m4] m5] or [a.b.c.d m1]。

更新：Xcode 4.4 引入了“An Objective-C 类扩展头”，在我看来，就是以某种方式提供“包私有访问控制”，所以如果你包含扩展头，你可以调用我的“包私有”方法；如果只包含我的公共标头，则只能调用我的公共 API。

【讨论】：

【解决方案3】：

不幸的是，objective c 没有任何等同于 C#、c++ 和 java 包的命名空间......

命名冲突可以通过给出上下文名称来解决，例如，如果你要给方法一个名称，它应该暗示它进来的类和模块，这样……这些问题就可以避免。

通过以下网址了解有关苹果建议的命名约定的更多信息

http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/ProgrammingWithObjectiveC/Conventions/Conventions.html

【讨论】：

【解决方案4】：

他们使用长名称...

Article on coding style & naming in Cocoa / Objective-C
Discussion whether Obj-C needs namespaces（已删除，归档here）

【讨论】：

不幸的是，dotnetdevelopersjournal.com 似乎已经消失了。
感谢您的提醒，我添加了一个存档链接。这很丑，但文字在那里。

【解决方案5】：

问题 1：Java 包的 Objective-C 等价物？

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

一个小的澄清（虽然它并没有太多的安慰）是 Objective-C 实际上有两个平面命名空间——一个用于类，一个用于协议（如 Java 的接口）。这并不能解决任何类命名冲突，但它确实意味着您可以拥有同名的协议和类（如<NSObject> 和NSObject），后者通常采用（“实现”）前者。此功能可以防止“Foo / FooImpl”模式在 Java 中猖獗，但遗憾的是对类冲突没有帮助。

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

命名

以下规则是主观的，但它们是为 Objective-C 类命名的良好准则。

如果您的代码不能由其他代码运行（它不是框架、插件等，而是最终用户应用程序或工具），您只需避免与您链接的代码发生冲突。通常，这意味着您可以完全不使用前缀，只要您使用的框架/插件/捆绑包具有适当的命名空间。
如果您正在开发“组件化”代码（如框架、插件等），您应该选择一个前缀（希望是唯一的）并在可见的地方记录您对它的使用，以便其他人知道以避免潜在的冲突。例如，CocoaDev wiki "registry" 是一个事实上的公共论坛，用于在前缀上调用“dibs”。但是，如果您的代码类似于公司内部框架，则您可以使用其他人已经使用的前缀，只要您不使用带有该前缀的任何东西。

组织

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

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

我的意见

虽然拥有包/命名空间机制可能会很好，但不要屏住呼吸等待它发生。 类冲突在实践中非常罕见，并且在发生时通常非常明显。命名空间确实是解决 Objective-C 中非问题的解决方案。（此外，添加命名空间可以避免使用前缀等变通方法，但可能会在方法调用等方面引入更多复杂性。）

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

【讨论】：

所以你是说 Xcode 中的逻辑组织，它独立于磁盘位置并且更多地为了开发者的方便，是组织类的唯一方法？

【解决方案6】：

请参阅 What is the best way to solve an Objective-C namespace collision? ，了解有关 Objective-C 如何没有命名空间的讨论，以及由此产生的痛苦 hack。

【讨论】：