vlambda博客
学习文章列表

API设计的黄金法则

API设计很困难，尤其当API会被大规模使用。如果你正在设计的API有成百上千位用户访问，你必须考虑未来怎么修改它，以及修改是否会破坏客户端代码。除此之外，你还需要考虑API的用户对你的影响。如果一个API类在调用它自身的一个内部方法，你必须记住用户可能会创造其子类并重载那个[内部]方法，这可能会导致灾难性后果。那时你无法改变那个方法，因为一些用户已经赋予它不同的意义。[该API类]未来内部实现（internal implementation）的选择完全取决于用户。

API开发人员能用各种方法解决这个问题，但最简单的方法是锁住（lock down）API。如果你用的是Java，那么你可能会想到给大多数的类和方法加上final。对于C#，你可以用sealed。不管使用的是哪一种语言，你都可以试图通过单例模式或静态工厂方法模式来提供你的API，这样你就可以防止别人的重载并限制使用API的编程方式。这一切看似都很合理，但真的是这样吗？

在过去的十年里，我们逐渐意识到单元测试是工程实践中极其重要的一部分，但是这一经验并没有完全普及到行业中。在我们身边都是证据。你随便找一个调用第三方API的未测试过的类，然后试着给它编写单元测试。大多数时候你会遇到困难。你会发现调用API的代码像胶水一样粘在上面。你没有办法模拟API类，来感知它和代码之间的交互，或者提供[API]返回值来完成测试。

随着时间的推移，情况会越来越好，但前提是在设计API的时候我们便开始将测试看作一个真实用例。很遗憾，这比测试代码要更加复杂。这引出了API设计的黄金法则：仅仅为你开发的API编写测试是不够的；你必须为API的使用代码编写单元测试[1]。当你这样做时，你就会直接了解用户在尝试独立地测试代码时必须克服的障碍。

没有单一的方法让开发人员轻松地测试使用你的API的代码。static，final，和sealed本身不是坏的结构。有时它们是有用的。但是，意识到[可能出现的]测试问题是很重要的，而要做到这一点你必须亲身体验。一旦你体验到了，你就能处理好它，和处理其他设计挑战一样。

[1]“It's not enough to write tests for an API you develop; you have to write unit tests for code that uses your API.”

我觉得这个黄金法则更好的一个版本是“你必须让使用你的API的代码能够编写单元测试”，而不是“你必须为使用你的API的代码编写单元测试”；前者是结果，后者是寻求这个结果的有效方法之一，当然也是最简单直接的一个方法。如果没测试过自己设计的接口，那么这个接口的设计犹如纸上谈兵。 

相关阅读：