
26
|
第
2
章
模块化原则
2.1.2
API
优先原则
一个模块的好坏取决于它的公共接口。一个极好的接口后面可能隐藏着一
个糟糕的实现。更重要的是,一个好的接口意味着,只要我们有时间引入
一个更好的实现,就可以替换掉原先那个较差的实现。由于
API
保持不变,
我们可以决定是全部替换现有的实现,还是在使用者升级到新版本时保持
两者共存。
有缺陷的
API
很难修复。有一些实现可能依赖我们打算修改的那个接口,
这意味着只要想对
API
本身进行更改,我们就必须让每个使用者更改其调
用该
API
的方式。随着项目的发展,这些可能需要调整的
API
被调用的次
数会不断增加,因而更难被修复。
专注于公共接口的设计是开发可维护组件系统的关键。设计精良的接口可
以通过引入符合该接口的新实现来经受住时间的考验。好的接口设计可以
使访问组件的最基本或最常见的用例变得简单,而且有足够的灵活性来支
持出现的其他用例。
一个接口通常不需要支持多个实现,但我们必须优先从公共
API
的角度来
思考。对实现进行抽象只是这个难题的一小部分。
API
设计的解决之道在
于弄清楚使用者需要哪些属性和方法,同时使接口尽可能小。
当我们需要实现一个新组件时,一条很好的经验法则是 :根据这个新组件
制定我们需要的
API
调用方式。例如,我们可能希望组件与
Elasticsearch
REST API
交互。
Elasticsearch
是一个具有高级搜索和分析能力的数据库引
擎,其文档存储在索引中,并且按类型排列。
在下面这段代码中,我们想象使用一个
./elastic search
组件,该组件有 ...