[译] 狂野的 #imports: 如何驯服文件依赖关系

2024-02-29 09:03:41 浏览数 (1)

与所有基于 C 语言的语言一样，Objective-C 文件通常成对出现：有一个头文件和一个实现文件。头文件和实现文件都可以使用 #import 指令来包含其他头文件。如果不小心，很容易造成文件依赖性爆炸。后果是什么？如何控制 #import 依赖关系？

本文是Objective-C 中的代码气味系列文章中的一篇。

文件依赖性

.m 文件中不必要的 #imports 会造成困扰。为什么？因为它迫使你在项目中使用其他文件。当你在一个项目中工作时，这并不是什么大问题，但当你开始一个新项目并想重复使用一些源文件时，这就会立刻带来麻烦。

但是，.h 文件中不必要的 #imports 会更糟糕：问题会呈指数级增长！这是因为一个头文件导入了另一个头文件，而另一个头文件又导入了另一个头文件，如此循环。把它想象成一个依赖关系图：

依赖关系

问题：增量构建时间

文件依赖性也会影响增量构建。修改 D.h 会导致 Xcode 重新构建 D.m、B.m 和 A.m。但请相信我：在大型项目中，一切都会陷入僵局。有人告诉我："这不重要。反正我也需要休息一会儿，所以我不介意等它建好"。但这么说的人并没有进行测试驱动开发。在 TDD 中，单元测试会对你刚刚修改的代码给出反馈。你越能收紧反馈回路，就越能保持 "在状态"。哪怕只有几秒钟，也会产生不同的效果。

问题：隐藏的依赖关系

虽然头文件中不规范的 #imports 会影响编译时间，但不要以为实现文件就不会受到影响！依赖关系图仍然在起作用，只是作用方式不那么明显。

让我们参考同一张图，但稍作改动。假设 A.m 导入了 B.h 和 C.h，但 B.m 导入了 D.h。这里的问题并不是因为导入 D 会导致太多模块需要重新编译。问题在于，要在项目中包含 A，就必须把 B、C 和 D 也拖进来。您可以通过读取 A.m 的 #import 指令来扫描 A.m，找到第一层文件依赖关系。但对 D 的依赖是隐藏的。直到你添加了 B，构建失败时才会发现它。

当你在依赖关系图中逐级往下追寻时，尝试添加一个模块 A 很快就会成为一件令人沮丧的事情。

代码气味： .h 中的 #imports 数量过多

因此，让我们来看看如何驯服文件依赖关系，首先是头文件，然后是实现文件。从头文件开始，要注意的代码问题很简单：#imports 太多。让我们考虑一下哪些 #imports 是必要的，哪些是可以避免的。

假设我们要定义一个类 Foo。它继承自 Superclass，并实现了两个协议：

代码语言：javascript复制
@interface Foo : Superclass <Protocol1, Protocol2>
// ...
@end

有必要 #import 定义 Superclass、Protocol1 和 Protocol2 的头文件。

那么作为实例变量或属性的对象呢？其他协议呢？作为参数传递或由方法返回的对象呢？让我们填写 Foo 的声明内容：

代码语言：javascript复制
@interface Foo : Superclass <Protocol1, Protocol2>
{
    Bar *bar;
}
@property(nonatomic, retain) id <DelegateProtocol> delegate;
- (void)methodWithArg:(Baz *)baz;
- (Qux *)qux;
@end

我们添加了对 Bar、DelegateProtocol、Baz 和 Qux 的引用。我们需要导入多少个声明？答案是不需要！我们只需在 @interface之前前置声明即可：

代码语言：javascript复制
@class Bar;
@class Baz;
@class Qux;
@protocol DelegateProtocol;

有些人喜欢将所有 @class 前置声明合并在一行，但我更喜欢每行一个。这样我就可以对它们进行排序，进而帮助我找到任何重复的声明。此外，每行一个声明还能显示有多少个声明。

注意：对于来自 UIKit 等内置框架的类，只需 #import 该框架，而不必对每个类进行前置声明。框架是一个带有主头文件的预编译块，因此它不会影响文件依赖关系的粒度。对于任何框架和库来说，这都是一条很好的规则，除非你在构建过程中创建了一个特定的库。

......回到我们的例子，我们唯一需要 #import的头文件是那些声明我们要继承的超类和我们要实现的协议的头文件：

代码语言：javascript复制
#import "Superclass.h"
#import "Protocol1.h"
#import "Protocol2.h"

我们可能还需要引入其他非对象声明，例如枚举和类型定义，但一般来说，在头文件中包含任何其他 #imports 都是一种代码缺陷。

这也是为什么我把协议声明放在自己的头文件中，而不是与它们合作的类放在一起。这样可以保持依赖关系图的简洁。

代码气味: .m 中的 #imports 数量过多

前置声明在实现文件中并不常见，因为我们通常是向对象发送信息，而不仅仅是传递对象。(不过，如果你的类是委托的中间人，你会发现有时方法会从返回值中获取一个参数，并将其作为自己的返回值传回。那就看看能否使用前置声明，避免 #import）。

因此，我们通常不能在 .m 文件中使用前置声明来修剪 #imports。但在 .h 和 .m 文件中，#imports 都会随着时间的推移而累积。有一些 #imports 是不必要的，可以直接删除。这种情况发生在:

  • 在开始新工程时，你会习惯性地添加某些 #imports，因为它们是你常规工具包的一部分。但实际上，你从未使用过每种工具。
  • 你可以从类中删除对象引用。但你永远不会返回去删除它的 header 引用。

从根本上说，这就是 "冗余管理"。偶尔清理一下杂乱的 #import，可以减少不必要的文件依赖。在下一篇关于#import完整性（与导入过多相反）的文章中，我将分享为什么 #import 顺序很重要。

但是，即使你放弃了所有不必要的 #import，你仍然会在一个长长的列表中看到一个又一个的#import。在开发过程中，很容易将越来越多的东西集中到一个类中。内聚性会下降（因为类要做的事情太多），耦合度会增加。结果就是一个可怕的依赖关系图。

马丁-福勒（Martin Fowler）在《重构》一书中描述了一种名为 "大类"（Large Class）的代码气味，其指标是实例变量过多。我认为过多的 #imports 是大类气味的另一个指标（由此可见，过多的前置声明也是一个指标）。 遵循大类的建议：使用 Extract Class 或 Extract Subclass 重构步骤来分解东西。你会惊喜地发现其中的差别！"高内聚性 "将从一种理论变成你能切实感受到的东西。

摘要

让我们把这一切带回家！以下是管理文件依赖关系时需要注意的事项：

头文件中的 #import：

  • #import 你要继承的超类，以及你要实现的协议。
  • 前置声明其他所有内容（除非来自框架的主头文件）。
  • 尽量消除所有其他 #import。
  • 在各自的头文件中声明协议，以减少依赖性。
  • 前置声明太多？那您拥有一个“大类”。

实现文件中的 #import：

  • 消除没有被使用的 #import。
  • 如果一个方法委托给另一个对象并返回它所得到的结果，请尝试前置声明该对象，而不是导入它。
  • 如果包含一个模块会迫使你包含一级又一级的连续依赖关系，那么你可能有一组类想成为一个库。将其作为一个单独的库，并带有主头文件，这样就可以将所有内容作为一个预编译块引入。
  • #import 太多？那您拥有一个“大类”。

好了，去检查你的代码吧！我要去检查我自己的代码，因为我知道我有遗漏的地方。让我们来驯服那些疯狂的文件依赖关系！

译自 Jon Reid 的 Wild #imports: How to Tame File Dependencies 侵删

编译 对象 继承 框架 协议

0 人点赞