逐步改善，设计优秀的API( 三 ) _api

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