WINDOWS 。如果你学会了API，首要的收获便是对WINDOWS体系结构的认识 。这个收获是来自不易的 。
5. 如何设计一个优秀的API 下图是我自己当下的一些总结，慢慢维护：网上搜索了一下，一个多月前，“标点符”已经发布了下面这篇文章，觉得写得非常不错 --------------------------------------------到目前为止，已经负责API接近两年了，这两年中发现现有的API存在的问题越来越多，但很多API一旦发布后就不再能修改了，即时升级和维护是必须的 。
一旦API发生变化，就可能对相关的调用者带来巨大的代价，用户需要排查所有调用的代码，需要调整所有与之相关的部分，这些工作对他们来说都是额外的 。如果辛辛苦苦完成这些以后，还发现了相关的bug，那对用户的打击就更大 。
如果API经常发生变化，用户就会失去对提供方失去信心，从而也会影响目前的业务 。但是我们为什么还要修改API呢？为了API看起来更加漂亮？为了提供更多功能？为了提供更好的性能？还是仅仅觉得到了改变了时候了？对于用户来说，他们更愿意使用一个稳定但是看起来不那么时髦的API，这并不意味着我们不再改进API了 。
当糟糕的API带来的维护成本越来越大时，我想就是我们去重构它的时候 。如果可以回头重新再做一遍，那么我心目中的优秀的API应该是怎么样的？判断一个API是否优秀，并不是简单地根据第一个版本给出判断的，而是要看随着时间的推移，该API是否还能存在，是否仍旧保持得不错 。
槽糕的API接口各种各样，但是好的API接口对于用户来说必须满足以下几个点：易学习：有完善的文档及提供尽可能多的示例和可copy-paste的代码，像其他设计工作一样，你应该应用最小惊讶原则 。易使用：没有复杂的程序、复杂的细节，易于学习；灵活的API允许按字段排序、可自定义分页、排序和筛选等 。
一个完整的API意味着被期望的功能都包含在内 。难误用：对详细的错误提示，有些经验的用户可以直接使用API而不需要阅读文档 。
而对于开发人员来说，要求又是不一样的：易阅读：代码的编写只需要一次一次，但是当调试或者修改的时候都需要对代码进行阅读 。易开发：个最小化的接口是使用尽可能少的类以及尽可能少的类成员 。
这样使得理解、记忆、调试以及改变API更容易 。如何做到以上几点，以下是一些总结：1、面向用例设计如果一个API被广泛使用了，那么就不可能了解所有使用该API的用户 。
如果设计者希望能够设计出被广泛使用的API，那么必须站在用户的角度来理解如何设计API库，以及如何才能设计出这样的API库 。2、采用良好的设计思路在设计过程中，如果能按照下面的方式来进行设计，会让这个API生命更长久面向用例的设计，收集用户建议，把自己模拟成用户，保证API设计的易用和合理保证后续的需求可以通过扩展的形式完成第一版做尽量少的内容，由于新需求可以通过扩展的形式完成，因此尽量少做事情是抑制API设计错误的一个有效方案对外提供清晰的API和文档规范，避免用户错误的使用API，尤其是避免API（见第一节）靠后级别的API被用户知晓与误用除此之外，下面还列出了一些具体的设计方法：方法优于属性工厂方法优于构造函数避免过多继承避免由于优化或者复用代码影响API面向接口编程扩展参数应当是便利的对组件进行合理定位，确定暴露多少接口提供扩展点3、避免极端的意见在设计API的时候，一定要避免任何极端的意见，尤其是以下几点：必须漂亮（API不一定需要漂亮）API必须被正确地使用（用户很难理解如何正确的使用API,API的设计者要充分考虑API被误用的情况：如果一个API可能会被误用，那么它一定会被误用）必须简单（我们总会面临复杂的需求，能两者兼顾的API是更好的API）必须高性能（性能可以通过其他手段优化，不应该影响API的设计）必须绝对兼容（尽管本文一直提到如何保证兼容，但是我们仍然要意识到，一些极少情况下会遇到的不兼容是可以容忍的）4、有效的API评审API设计完成以后，需要经过周密的设计评审，评审的重点如下：用例驱动，评审前必须提供完善的使用用例，确保用例的合理性和完备性 。