objective-c - Cocoa:在头文件中导入和在主文件中导入有什么区别？

Question

我不知道为什么，但有时我设法修复了一些编译错误，最值得注意的是

error expected specifier-qualifier-list before 'someClass'

通过将 #import "someClass.h" 从 .h 文件移动到 .m 文件中。这也解决了我遇到的其他几个与标题相关的问题(从我的角度来看是神秘的)。

一些粗略的谷歌搜索找到了答案“永远不要在头文件中导入头文件”，这就是建议停止的地方。

要么我完全编造了这个，要么我从某个地方养成了习惯，但我认为标题是标题应该被导入的地方。显然不是，但谁能向我解释为什么会这样，以及导入 header 的首选方式是什么？

Answer 1

John 给出了很好的建议，但这里有更多关于原因、原因和异常(exception)的背景信息。

避免将 header 导入 header 背后有两个目标:改进增量构建时间和避免循环依赖。如果您将 A.h 导入到 B.h 并将 B.h 导入到 C.h，那么每次您更改 中的任何内容时A.h，你必须重新编译 C.m，即使 C.m 没有使用 A.h 中定义的任何东西。这可能会导致非常糟糕和不必要的构建困惑，尤其是当您的 header 经常更改时(这在开发的早期阶段很常见)。

第一个目标值得称赞，但对于小型项目，谁在乎呢？你有一个四核 Pro 和一个完整的构建需要几分钟，对吧？但是你还是要担心第二个问题:循环依赖。 A.h 引用类 B 和 B.h 引用类 A。这实际上可能经常发生，并且可能很无辜地潜入系统。集合对象可能引用它包含的对象的类型，而对象可能引用集合对象的类型。由于采用或返回该类型的某些方法，它所需要的只是一个单一的引用。如果您有导入其他 header 的 header ，则发生这种情况的可能性会迅速接近统一。您以递归导入结束，编译时错误可能令人震惊。 “我知道定义了 typdef!它就在那里!它是导入的!”但是，当您导入 this header 时，它还没有被解析。这就是导致上述错误的原因。

因此，即使您不太关心构建时间(尽管您应该)，也请避免将 header 导入 header 中……除了……

您要导入的一些 header 。当然是你的父类(super class)。定义您实现的 @protocol 或您使用的 typedef 的文件。所以是的，你必须包括那些。

那么系统 header 呢？好吧，它们永远不会导致流失，显然它们不会导致递归导入，所以它们很好。我不鼓励人们对系统 header 中的内容使用 @class 前向声明。它会毫无值(value)地为您的 header 用户创建额外的工作。为了良好的 header 卫生，请记住将系统 header 括在 <尖括号> 中，并将您的 header 括在“引号”中。

所以这不是一个微不足道的问题，但简单的规则是:避免在编译器允许的任何时候将用户 header 导入其他用户 header 。