[翻译]API设计黄金法则

API设计黄金法则

原文: http://programmer.97things.oreilly.com/wiki/index.php/The_Golden_Rule_of_API_Design
API的设计通常是一项艰巨的任务,尤其当设计的API非常庞大时. 如果你设计的API将会有成百上千的用户时,你要考虑今后应该如何扩展来避免不小心把客户端的代码搞挂. 除此之外,你还要考虑用户在使用API的过程中对你的影响.如果你的API类使用它内部的一个方法时,你要记得 – 用户可以通过子类复写(override)他,而这,可能会是灾难性的. 你将不能修改那些方法,因为用户已经这样使用它们了. 你今后的内部实现将无可避免的由你的用户来决定,而不再是你.

API程序员有各种各样的方法来解决这个问题,但最简单的还是禁止用户修改API.如果你用的是Java你可能会把所有的类都声明为final,如果用C#,则声明所有的方法为sealed.无论用什么语言,你都可以通过单例(singleton)或者静态工厂方法来避免用户复写代码,或者不当的扩展和使用你的代码.这些听起来很有道理,但,真是这样吗?

在过去的10年,我们渐渐意识到单元测试是一种非常非常重要的实践,但这一实践却并没有完全被整个行业所认可. 显而易见的是,大多数情况下,为一个未经测试的类编写测试用例时总是很难.你会发现使用了API的代码和API耦合的就像是上了强力胶一样.没有办法去模拟API类的行为,进而容易的测试API和你的代码之间的交互.

经过一段时间后也许会有改善,但只有我们在开始设计API时就考虑到测试问题.不幸的是,这可能需要你(API的设计者)多花一点时间 – 不仅测试自己的代码,还要考虑用户如何测试他们的代码. 这里就引出了伟大的”API设计黄金法则”: 仅仅给API写测试用例是不够的;你还要为使用API的代码写单元测试.只有这样做了,你才会在第一时间体会用户在使用你的API时进行测试时的种种问题.

让API易于测试的方法有很多.static,final和sealed并不见得是不合理的,他们有相应的使用场景.但意识到测试问题是很重要的,最好的办法就是自己去感受.一旦你这样做了,你将更加胜任各种设计挑战.

By Michael Feathers

Comments are closed.