算法(4th ed)(98):基础——数据抽象 4.5.2

阅读数:22 2019 年 11 月 2 日 12:15

算法(4th ed)(98):基础——数据抽象 4.5.2

(数据类型的设计:设计 API)

构建现代软件最重要也最有挑战的一项任务就是设计 API。它需要经验、思考和反复的修改,但设计一份优秀的 API 所付出的所有时间都能从调试和代码复用所节省的时间中获得回报。为一个小程序给出一份 API 似乎有些多余,但你应该按照能够复用的方式编写每个程序。理想情况下,一份 API 应该能够清楚地说明所有可能的输入和副作用,然后我们应该先写出检查实现是否与 API 相符的程序。但不幸的是,计算机科学理论中一个叫做说明书问题(specification problem)的基础结论说明这个目标是不可能实现的。简单地说,这样一份说明书应该用一种类似于编程语言的形式语言编写。而从数学上可以证明,判定这样两个程序进行的计算是否相同是不可能的。因此,我们的 API 将是与抽象数据类型相关联的值以及一系列构造函数和实例方法的目的和副作用的自然语言描述。为了验证我们的设计,我们会在 API 附近的正文中给出一些用例代码。但是,这些宏观概述之中也隐藏着每一份 API 设计都可能落入的无数陷阱。

  • API 可能会难以实现:实现的开发非常困难,甚至不可能。
  • API 可能会难以使用:用例代码甚至比没有 API 时更复杂。
  • API 的范围可能太窄:缺少用例所需的方法。
  • API 的范围可能太宽:包含许多不会被任何用例调用的方法。这种缺陷可能是最常见的,并且也是最难以避免的。API 的大小一般会随着时间而增长,因为向已有的 API 中添加新方法很简单,但在不破坏已有用例程序的前提下从中删除方法却很困难。
  • API 可能会太粗略:无法提供有效的抽象。
  • API 可能会太详细:抽象过于细致或是发散而无法使用。
  • API 可能会过于依赖某种特定的数据表示:用例代码可能会因此无法从数据表示的细节中解脱出来。要避免这种缺陷也是很困难的,因为数据表示显然是抽象数据类型实现的核心。

这些考虑有时又被总结为另一句格言:只为用例提供它们所需要的,仅此而已

评论

发布