设计好的API( 四 ) _兼容

一个API的生命周期
开发API的过程其实就是一个沟通交流的过程。沟通的双方就是API用户和API设计者。
API有可能是这样产生的，有些人写了一些代码，而另外的人发现这些代码的价值，就开始使用这些代码。在这种情况下，API是以一种自然的方式产生的。随后API用户和API作者有了相互沟通的渠道，开始交流经验，可能发现这个功能一开始的设计并不是很通用，或者说一开始时，作者并没有把这个功能当成一个API来设计。为了让这个功能成为一个API，他们开始讨论如何进行调整才能改善这个功能。经过几轮的迭代，才会带来一个有用而且稳定的API 。
但再换一个角度来看，API设计者希望在没有对外提供一个API之前就能和相关的用户进行沟通。这种API的开发方式更接近于基于业务的设计方式。在这种场景下，系统中的两个组件间的协定是已经明确的，至少说也是已经有了需求。收集需求，定义问题域，明确用例，再由指定人员来设计API 。现在，其他人员就可以使用这个API，并可以给出自己的建议，列出Bug，提出一些功能方面的改进意见。这些建议都有助于改进API，使其用途更广，也更稳定。
尽管这些API的案例各有其不同的缘由，但有相同的特点：每一个都需要时间来让用户进行试用，并进行反馈，然后才能宣称这个API是可以正常运行的。当然不是说这样做就可以带来稳定的API，有时候，也有可能最终什么都得不到。如果出现这种情况，最好还是放弃这个API吧。有时候，可能交流的双方无法进行高质量的正式交流。在开始的时候可以简单地聊一下，交流相应的需求，但如果新发布的版本也证明了这种简单的沟通方式并不合适，那么双方也许应该更进一步地进行交流，使得沟通能更简单更有效一些。
一切皆有可能。但对于那种开发人员之间的沟通问题，最好还是要描述清楚。如果你要设计一个API，那么在这个API没有成熟前，最好能够清楚地告诉其用户：“这个API还没有完善，你可以尝试使用这个API，但一定要小心。”在有了稳定的版本以后，还可以骄傲地告诉用户：“这是我开发过的最好的API！放心使用这些API，我可以保证它能一直提供支持。”这样做可以俘获API用户的“芳心”，让他们“拜倒在你的石榴裙”下。但请一定要注意，对于API，要能够清楚地标识其当前状态，以便用户了解相应版本是否可以稳定使用。
如果想告诉类库的用户当前发布的版本还不稳定，那么最简单的方式就是把其版本标识为0.x 。因为它还没有到达1.0版本，表示还在开发中，也就可能还会有所变化。不管用哪种版本标识方式，最重要的是要让API的用户清楚地知道当前版本的状态，以便他们决定如何使用该API 。
逐步改善
我已经提过多次，这里再多重复一次，第一个版本远非完美。事实上，不仅第一个版本，哪个版本都不会是一个完美的版本。不管怎么样，设计的场景不可能完全准确，不可能完全符合之前的方案。对于版本间的变化，也有两种极端的处理方式：一种是逐步改善，还是一种则是完全重写。
什么叫逐步改善呢？比如说，增加了一个方法或一个类，或者是向DTD文件中加了一个新的元素，又或者是增加了一个能够影响类库功能的属性。在保证老版本API能正常运行的情况下，演化出新版本API 。这种改进是一步步进行的。
关于“逐步改善”有一个谬论，就是说“因为只有少许的改动，所以以前用户使用老版本API编写的程序可以在新版本上继续运行” 。每一个改变都有潜在的风险，因为它可能引发一个甚至更多的不兼容问题。每一个不兼容问题（即使看似微不足道）都会反映到客户开发的程序中，可能就会产生非常严重的后果。开始时，要能够把真正的内容与最初的设想保持一致，而且任何一个小的改变都不会引发任何问题，这样才可能避免阿米巴虫模型出现。