何时在实现文件中包含#import

Question

学习目标C和其他基于c的语言我了解到，您应该将#includes和#imports放在头文件中。 @class也会去那里。最近查看来自苹果和其他Web源代码的示例代码，@class位于标题中，所有导入都位于实现文件中。

这是正确的吗？两者都有理由吗？如果您要导入头文件，为什么还需要提供@class声明。

Answer 1

两种情况都不是“更正确”，这两种行为都有明确的原因。例如，考虑其中有向其他类型的一个对象的引用，其中有两个类别的情况下，每个：

ClassA.h：

@interface ClassA : NSObject 
{ 
    ClassB *b; 
} 

ClassB.h：

@interface ClassB : NSObject 
{ 
    ClassA *a; 
} 

这段代码不会编译 - 你在这些头文件中有循环依赖。解决方案是使用@class指令转发声明所需的类。

在头文件中您可能更喜欢#import指令的情况可能是因为除了只关心其他头文件中的类名称（可能是C样式函数或枚举类型或某物）之外，还有一些通用代码。

Answer 2

学习Objective-C和其他基于c的语言我了解到，您应该将#includes和#imports放在头文件中。

否 - 不在c语言中。你应该尽可能将它们放在实现文件中。你不能总是创建一个零依赖头，但你应该尽量减少它。

基于c的语言编译需要很长时间，特别是当依赖和包含非常复杂，或者有不必要的包含（引入更多的依赖关系时，巧合）。

@class也去那里。最近查看来自苹果和其他Web源代码的示例代码，@class位于标题中，所有导入都位于实现文件中。哪个是对的？

使用前向声明（@class NAME;，@protocol NAME;，struct NAME，类名;`等）的地方就可以了。

两者都有原因吗？

包含在头文件中是一种懒惰的方式，它会减慢构建时间并引入大量的依赖关系。这很方便，因为您不必编写尽可能多的包含/导入声明，但对于必须使用您的程序的用户来说，这是不体贴的。

此外，如果您要导入头文件，为什么还需要提供@class声明。

如果类接口已经可见（已被包含，或者其他文件声明了它），则不需要两者。如果您打算使用该类型（除了一些非常微不足道的情况），您将需要可见的界面。

一旦构建时间增长缓慢，您一定不会很兴奋纠正错误 - 最好是使用正确的方法学习和实施。如果你还没有开发出一个复杂的c项目，那么你很可能会很惊讶地发现在编译时丢失了多少时间。

如果您希望您的程序永远不会变得平淡无奇，并且永远不会共享或重复使用，请根据您的喜好选择。

祝你好运！