如果你想说服其他程序员使用你设计的API，那么必须先取得他们的信任。你需要让这些程序员们相信，你有能力来设计、编写和维护一个稳定的API，而且能在后续的多个版本中坚持做到这一点。即使不考虑使用一个API有多困难，如果该API的新版本发布后，所有的客户端代码都需要重写，这简直就是厄运的开始。想一下，有这么多的开发商①在微软的Windows平台开发程序，如果因为Windows用户安装了一个操作系统的新版本，所有的程序都无法正常运行了，估计真是一场大的厄运。因此API设计会涉及一个信任问题：通过遵守本书给出的最佳实践，可以有效地减少不兼容问题，从而获得用户的信任。 有时对兼容性的破坏是无法避免的，毕竟我们生活在一个现实世界，绝不可能尽善尽美。但只要存在着相应的可能性，就应该避免破坏兼容性。将一些内容标识为不建议使用，然后明确以文档的形式来告诉用户如何将现有的系统迁移到新组件，这些对于组件的用户来说是可以接受的。但如果某个组件每个新版本都会进行一番大的改动，那么客户可能会直接放弃这个组件，选择另一个组件，以避免这种迁移的痛苦。对组件的用户来说，如果组件不兼容，成本将非常高昂，简直就是对用户的一种惩罚。这将导致失去用户的信任。 有些人会说，如果加把劲，多用点心，即使是第一个版本，也可能实现一个完美的API。他们说的可能正确，但必须费心劳力才有可能达到这个目标。即使你已经尽了最大的努力，设计API时所面对的需求仍然可能会随着时间而调整。如果需求产生了变化，最好的情况是API提供的功能不够用了，最差的情况就是，因为需求的改变，使得API提供的功能已经完全无用了。无论何种情况下，设计一个API就必须提前做好准备，使得在需求改变的情况下，API也能随之改变，而且不会破坏其用户的现有代码。因此，我后面会用很多篇幅来讨论API设计如何考虑后续改动的需求。 没有借口 事实上，第一个版本几乎从来没有完美的，但不能说这是因为第一次设计，所以设计上做得不好，这不应该成为一个借口！对于第一个版本来说，设计起来总是比较容易的，而在后续版本中加以改进则比较困难。所以在第一个版本中，要尽量将其设计做到完美，同时不要忘记，今天看来完美的设计，明天可能就变得非常差。改变迟早都会出现。 开发API的第一个版本通常比较容易，问题往往来自于后续版本。要对一个API加以改变，并加入一些新功能，但同时还不能影响原来的功能，这是一门精妙的艺术，既要考虑原有的API被使用的所有方式，还要保证这些用法适用于新版本，太困难了。 对API进行改进是一件不可避免的事情，因此对于用户来说，API必须能够在后续的时间里得以改进。我们必须努力做到在保证一个组件的可靠性的时候，还能修正其bug并处理用户的新需求。要做到这一点，就要避免“闭门造车”。如果在设计API时就考虑到未来改进，而预先留出相应的空间，那么即使出现升级的情况，也不会给其用户添加额外的工作。 好比言论自由 除了改进以外，决定API好坏的还有其他多方面重要的内容。API必须有对应的文档，它也应该容易被用户了解和使用。但除了这些内容以外，能够被改进才是最重要的。如果API能够被持续改进，那么初始版本中的问题就能在新版本中修正。 如果你拥有言论自由的权利，你就可以说出其他缺失的权利，并要求拥有这些权利。如果将要失去某些其他东西，你可以去努力争取并可能最终得到它。 如果API已经为其后续的改进做好了准备，虽然它现在有些丑陋，而且缺乏文档，还很难使用，但这些问题都可以通过发布一个新版本，并且更新API来加以修复。这正是我为什么把改进看作API最重要的内容，在设计一个功能库和其接口时，应该将其放在首位。 因为开发人员不喜欢那些不必要的工作，特别是那些因为库的开发商考虑不全面，最终使得库无法兼容，进而为开发人员带来一些不必要的工作，所以在开发可供他人使用的组件时，必须要考虑在组件改进的时候还能保持兼容。 ① 这里所谓的开发商，只是一个统称，任何开发任何的人员或者公司，也不管他们是否为商业，还是开源，都统一称为开发商，也可以称为开发方，但前者更为通用，所以译文沿用了该术语。——译者注
软件框架设计的艺术——2.5 开发第一个版本通常比较容易
书名： 软件框架设计的艺术
作者： [捷克] Jaroslav Tulach
出版社： 人民邮电出版社
原作名： Practical API Design: Confessions of a Java Framework Architect
译者： 王磊 | 朱兴
出版年： 2011-3
页数： 388
定价： 75.00元
装帧： 平装
丛书： 图灵程序设计丛书
ISBN： 9787115248497