
1.4
模块化的粒度
|
13
令其使用者很满意,但在需要时,它也能用于高级或不那么常见的用例,
这样做不会对易用性造成太大的不利影响,也不会大大提高实现的复杂性。
在接下来的几章中,我们将讨论如何在灵活性、简单性、可组合性和适当
的未来规划之间权衡。
1.4
模块化的粒度
我们可以在给定系统的每一层上应用模块化设计的概念。如果项目的需求
超出了其初始范围,可能应该考虑将该项目拆分为几个较小的项目,由小
团队来开发,这样更易于管理。应用程序也是如此 :当它们变得庞大或复
杂到一定程度时,我们可能希望将它们拆分成不同的产品。
如果要使应用程序更易于维护,应该考虑创建显式定义的代码层,以便横
向拓展每个层,同时防止添加的那些内容中所含的复杂性蔓延到其他不相
关的层。对于单个组件也可以应用同样的思维 :将它们分成两个或更多个
较小的组件,由另一个小组件连接起来,这个小组件可以充当组合层,其
唯一的职责就是将几个底层组件组合在一起。
在模块层面,应该努力使函数简洁、有表现力、命名具有描述性,而且功
能尽量少。比如我们有一个函数,专门用于在特定异步流下将一组任务组
合在一起,同时为该控制流中需要执行的每个任务提供其他功能。顶层的
流控制函数可以作为模块的公共接口方法暴露出来,但它唯一应该被视为
公共接口的部分,是我们接收的作为该函数输入的参数和由该顶层函数产
生的输出。其他的都变成了实现的细节,因此被认为是可替换的。
模块的内部函数不必像接口那么严格 :只要公共接口保持不变,我们就可