如果此时你正在书店面对这本书，在买与不买之间犹豫不决，那是因为你无法判断这本书对你是否有用。老实说，这点我帮不了你，因为我不是你。但我可以告诉你我自己为什么需要这本书，以及我写作该书的缘由，这样也许可以帮助你决定是否应该购买此书。我在设计NetBeans框架的API时，就像在一片迷茫中寻找光明，总是摸不清方向。最开始，我完全凭直觉，而且认为写API是一种艺术。我知道对于艺术来讲，需要创造力，但设计API，与艺术是不同的范畴。时间慢慢过去，我从已经完成的工作中汲取经验，逐渐整理出一整套思路和度量标准，借助于这些可量化的标准，可以将一个普通的API优化成一个优秀的API。 本书介绍了NetBeans团队中一直以何种标准来评价API的质量，并清楚地说明我们团队为什么一直坚持使用这个标准。事实上，这些标准都是我们经过多年的尝试，并从错误中吸取教训，才最终得到的。地球人都知道，重新发明轮子并不是一个好主意，这是在浪费时间和金钱，所以对于那些把API设计更多地看作是一种工程而非艺术的架构师们，我郑重推荐此书。在NetBeans的初创阶段，只有我一个人来设计API 。当时，我们有一个比较极端的观点：“一群代码开发人员是不可能设计出一个好的API的。”其实对于一个单兵作战设计人员来说，即使没有任何规则来约束，他所设计的API也具有一致性。但像NetBeans这样的一个大团队，是不能只有一个设计人员的。所以，我的首要任务就是要去寻找一种方式，让更多的人能够设计API，同时还能保持整体设计上的一致性。那个时候我已经开始撰写本书，希望能告诉大家API设计方面的相关理论，以及我们编写API的原因和目标等，同时还根据我们过去的经验总结出一些规则，方便大家来量化一个API的设计质量。接下来，我将我的经验与NetBeans团队中的成员分享。从此，我开始放手让他们也来编写API，在开始和结束阶段花些时间来评审和指导他们的设计。以我的标准来衡量，可以说这么做很棒。这10年来，他们一直在努力地学习和进步，现在看来，我们设计的API具有了相当高的一致性，并满足了我们的大部分需求。如果你也处于相应的职位，需要评审或者指导他人来设计API，你将发现本书中的建议会对你有所裨益。 当我想为API给出一个定义时，却发现这个定义的范围非常广泛。要知道，不是说只有一个框架或者是通用库才算是API。即使只是写了一个普通的类，只要有同事使用了这个类，那么也算是写了一个API。为什么这样说呢？假设你删除了这个类中的一些方法，或者是改变了这些方法的名称，哪怕是改变了这个类的一些功能，这个类的使用者都会火冒三丈。为共享库写API也面临同样的问题。如果你所写的类有多个人使用了，那么你对该类的修改也许会强制要求所有用户都进行相应调整，这无异于一场噩梦。这种噩梦其实是可以避免的。如果在开始写代码时，就把一个类当成一个API来认真对待，你会少许多麻烦。换个角度来说，其实这事也不难，只需要设计类的时候再小心一些，在调整的时候多多关注它的兼容性，再参考和借鉴一些好的经验，其实都搞得定。如果根据前面所说的这个定义来分析一下，几乎所有的开发人员都在编写和设计API。 API的一个本质特性就是它的工作机制。API的测试是非常重要的，借助于它，可以更加清楚地说明API的原理。没有合适的测试，就不可能编写一个好的API。本书有几个章节会列出一些测试方式，告诉读者如何来有效地测试一个库的公开接口，而且即使是要处理该库的多个版本，也无碍于测试的正常运行。我会详细地说明测试时要注意的各项内容，包括签名①、单元测试和兼容性工具。所以，对于那些需要检查API兼容性的人来说，本书非常有价值。 最后要说的是，一个得到广泛使用的类库将会是该库作者的财富。如果这个类库能够很好地满足现有用户的需求，就会吸引更多的用户来使用，财富将会不停地增加。要知道，只有在类库拥有了大量的用户以后，才能在这个基础上获得经济利益，从而继续开发和维护这个类库。本书会就这一点展开讨论，那些喜欢从商业角度来审视软件开发的人会对这一个话题很感兴趣。 ① 所谓的签名就是英文中的signaure，表示一个类或一个方法的标识，它与序列化等多个方面都有关系，通常来说，一个类的签名是由其父类及其所有成员，包括字段和方法决定的，一个方法的签名则由参数或返回值确定。 ——译者注