如何设计优秀的API.docVIP

逐步改善，设计优秀API 判断一个API是否优秀，并不是简单地根据第一个版本给出判断的，而是要看多年后，该API是否还能 存在，是否仍旧保持得不错。 判断一个API是否优秀，并不是简单地根据第一个版本给出判断的，而是要看多年后，该API是否还能存在，是否仍旧保持得不错。 第一个版本远非完美 第一个版本总是来得特别容易，不仅容易开发，而且容易发布。API的需求会随着时间而变，那些过去有效的API可能现在已经不再适用了。而且每个程序中都会存在Bug，需要不断地来修复，这样做带来的副作用人所共知：修复一个Bug的同时会引入两个新Bug。这些观点普遍适用于所有软件系统，API也不例外。 但我们没必要为这个结论而感到悲观。API因为需要不断改进的事实算不上什么坏事，只是对现实的一种坦诚。每一个API的作者都应该为未来的改进做出计划。这种计划是一种比较高层次的，要考虑未来版本会对API中哪些内容加以改进。这种计划可能会用到两种方式。一种极端的方式是放弃老的版本，重新开始做一套新系统。还有一种方式则是修正用户提出的问题，并强化现有的API，保证兼容性，从而使得现有客户端的功能不会有所改变。 放弃现有的API，并从头开始编写一个新的API来完成同样的任务，可以避免不兼容问题。这样做唯一的问题就在于：那些使用旧API的客户端只能继续沿用老的API，除非重新编写他们的代码，以升级到API的新版本上。所以这样做的缺点也是不容忽视的。 完全重新编写API的优点在于避免了细微的不兼容问题，但让客户端被锁定在一个特定的版本中，即使新的版本提供了大量的改进，这些客户端也无法从新版本中获益。虽然对API进行改进固然是一件重要的事情，但相比之下，兼容性更为重要。只有在这两者之间巧妙地取得平衡才能让一个API成为可用的API。 向后兼容 对于每一个API的设计者来说，都渴望做到“向后兼容”，因为不管是现在的API用户，还是潜在的API用户，都只信任那些可兼容的API。但向后兼容有多个层次上的意义，而且不同层次的向后兼容，也意味着不同的重要性和复杂度。 源代码兼容 说到兼容性，最先要面对的问题，就是保证源代码编译时的兼容。如果基于Java 1.3版本开发程序，那么可以用Java 1.4版本来编译这些程序的源代码吗？如果能做到这一点，那么可以说Java 1.3和Java 1.4这两个版本是源代码兼容的。但源代码兼容是非常难以达到的。之所以出现这种问题，主要是因为每个新版本的Java语言都会添加一些语法上面的新功能，这种改变往往都会体现在执行文件的格式上，也就是Class文件的格式会有所调整。 二进制兼容 如果一个基于老版本类库开发的程序，在不需要重新编译的前提下，可以和新版本类库进行正常连接并执行，那么这种情况可以称作二进制兼容。因为有两种场景需要这种兼容性方面的支持，所以要做到这一点也是非常重要的。首先，用户基于某个版本的类库编写了一个程序以后，原先开发的程序应该都可以一直正常运行，不管用户手中的类库是哪个版本，是否升级到了必威体育精装版版本，程序的运行都应该是正常的。这样做可以极大地简化程序的维护、打包和发布工作。其次，如果用户只有一个老版本的二进制类库，也同样可以开发程序，随后再移植到新版本上，这样就无须用户来重新编译程序 。这两种场景都有各自的用途，它们提升了配置方面的灵活性，并赋予模块开发人员和用户更多的自由。为了达到这种相互调用的灵活性，开发人员至少需要了解一些源代码编译后生成的二进制格式。对于Java语言来说，就表示开发人员需要去了解Class文件的格式，以及Java虚拟机如何加载Class文件。 二进制字节码的格式与Java源代码的格式非常相似，这有好的方面，也有坏的一面。说它好，是因为这样的格式很容易理解。说它坏，是因为它会引发一些误解。但大家应该记住，在编写API的时候，只有通过二进制格式才能最终判断不同版本的API是否兼容，也就是说代码执行时的兼容性才是最根本的。所以一定要了解Java源代码是编译成何种样子的字节码。如果有疑问的话，最好反编译一下Class文件，检查一下到底是不是自己期望的样子。有可能你会为反编译的结果大吃一惊! 功能兼容——阿米巴变形虫效应 如果一个类库在运行时，不管所引用的是老版本还是新版本的类库，其产生的结果完全相同，那么这两个版本可以称为功能兼容。这个定义看起来简单，但背后的含义却不简单。 作为开发人员，你可能会清楚地知道你所开发类库都提供了哪些功能，假设你提供了优秀的规范和完善的文档还有其他的信息，从而能够清楚地对类库的功能加以说明。当然这只是一个假设，从来都没有什么优秀的文档可以做到上面所说的目标。在现实世界中，文档总是比程序慢上一步，而且其描述的信息也只是整个程序的一部分内容。但还是先假设有一些开发人员已经完美地分析了程序，