设计好的API( 三 ) _兼容

既然不知道自己的客户，自然也无法进行交流，那么就有两种解决方案：一是找一些用户，对其进行研究，还是一种方式就是基于用例。基于用例也就表示站在用户的视角，然后再对部分用例进行针对性的处理。从用户处取得反馈信息，并对可用性进行研究，这是一种很好的工作方式，可以通过反馈来检验设计的用例是否正确。在做设计之前，必须进行分析，明确为什么要写这样的API，API应该长什么样，以及如何才能完成目标。
当然这些用例都是编的。当API有了真实的用户时，才会发现这些用例与与真实情况可能相距甚远，与真实需求也有很多不同之处。从这一点上来说，第一个版本决不可能完美。但可以减少API中存在的错误。说到API设计错误，并不是指这些API不能满足用户需求，这是很正常的，因为在整个系统的生命周期中，会不断地有用户提出新的需求。所谓的错误是指API不能在后续的版本中以扩展的方式来满足用户的这些需求。但如果你学习了本书，在设计API时，不仅可以通过扩展的方式满足新需求，而且新版本也不会破坏客户基于第一个版本开发的那些代码。
前文展示的阿米巴变形虫模型说明了对外的功能描述和其内在实现之间是存在着差异的，正是这种“差异”引发了API维护中的主要问题。所以要尽可能地减少这种不一致。但想要实现这个目标也要有一个前提，就是能对外提供一个定义清楚而且明确的规范，否则没有规范，拿什么来进行比较呢！
API设计评审
过去，人们一直认为设计工作是不能由一个集体来完成的，它需要一个架构师对所有的设计进行决策。当然，这样做可以简化很多事情，但仍然有一个规模上的限制。就算不考虑模块规模大小这方面的限制，这位首席架构师的压力也是非常庞大的，其责任包括设计、维护API，还要告诉别人API应该怎么使用，这些工作内容都需要占用大量的时间，毕竟这位架构师一天只有24小时，不可能无限制地工作。
解决方法就是从团队成员中选择一些技术最好的人，指导他们来设计自己所需要的API 。但这样做会造成一致性方面的问题，因为每个人在设计API时都有其个人风格。肯定无益于API的质量，必须解决这一问题。
但每一个设计良好的API，都有着相同的动机。所以要有一个团队来配合API的作者对API进行评审工作。
一旦有一个API需要改动，任何人都可以提交一个改变的请求。其他人则需要在代码正式提交前，进行一次评审，检查新调整的内容是否符合一个优秀API的基本要求。比如说，我们会按照“优秀API规则”进行检查，保证能够满足这些规则。下面详细地列出了这些规则。
用例驱动的API设计：设计API时，要基于一些具体的场景和对API的认识进行抽象分析，最终给出设计。
API设计的一致性：API往往是由多位设计者来完成的，但整个团队中必须能够保持“最佳实践”的一些基本原则。一个接口设计得再好，只要它违反整个团队的一致性，就宁愿退而求其次。

文章插图
简单明了的API：简单而且常见的任务应该更容易处理。如果基于用例驱动的方式进行设计，就可以很容易地通过那些可以简单实现的场景来验证这些API是否可以完成那些重要的用例。
少即是多：一个API对外提供的功能应该只包括用例中说明的功能。这样可以避免出现需要的功能与实际提供的功能两者之间出现差异。
支持改进：以后也必须能够维护这个类库。如果出现新的需求，或者原作者离开，都不会出现放弃这个类库的情况。