理论上，如果每个班级都包括其他所有班级，那有多糟糕？

Question

想象一下拥有30个课程的iPhone应用程序。每个类都必须与其他类进行交互，因此每个类都包含29个其他类+基础框架。

我想了解包含课程时究竟发生了什么。这是否与应用程序中该类的内存大小相同？它对iPhone的内存占用和性能有害吗？也许有人会详细了解这一点并且可以解释。

请注意，这不是一个好的架构。关于“包含”对记忆和表现的影响，这是一个假设性的问题。

Answer 1

您可能遇到性能损失的唯一情况是在编译时。通过在类的标头中使用#import "MyClass.h"而不是@class MyClass，当MyClass的接口发生更改时，将重新编译它。这将为您的总编译时间增加一点，这可能会占用大型项目​​。

编辑（2009年8月29日）：我在上面的答案中将#include更改为#import，因为在ObjC中使用了以防止重复包含标题。

Answer 2

包含和实例化之间存在差异。如果每个类都试图实例化另一个类，那么这是非常糟糕的。

虽然，如果您只是提供对该文件的引用，以便可以从任何地方实例化任何类，那么您可能遇到的唯一问题是如果您尝试更改内容，则会出现错误路径。

例如，

更改一个文件（或类）的名称意味着您现在必须去纠正对该路径的其他29个错误引用。

据我所知，简单地包含文件（至少用我熟悉的语言）不会对你的表现产生不利影响。

Answer 3

通常，包含和作用域，面向对象等只是程序员的实用工具。如果你愿意，那就是一种秩序错觉。在机器代码级别，您可以随处访问流程的任何变量。您必须包含在程序中其他位置使用的标头，这只是语言创建者用来限制您当前需要考虑的事情，丢弃重复项等的方式，并且编译器可以帮助您验证您的该计划的“描述”是正确的。

如果您将可执行文件链接到其中，则只会使您的可执行文件更大。如Evernoob暗示的那样，你只会让它变慢，如果你产生了很多实例等。只是为其他类“知道”类型和定义不应该在运行时引起任何性能问题，但它通常会增加编译时间。

Answer 4

一般来说，尝试保持依赖性降低更多的是在一个类更改时不必更改大量代码。

简单地包含大量文件，它不一定是坏的 - 所有它会做的就是增加编译时间，但是在你有数百个文件（如果有的话）之前，这种增加不会真正引人注目。

要记住的其他事项是，在标题与类文件中包含之间存在差异。如果您从标题中包含一个类定义，而该标题又包含您所在的标题，则您有一个循环引用，您必须使用@class指令将其中一个类引用声明为转发类。事实上，标准理论上在头文件中使用“@class”，在实现中使用“@import”，但通常你不会遇到彼此引用的类，所以标题中的#import也可以，并且打字少了一点。