理论概述
软件开发并不需要了解每一个API背后的实现原理，只要知道它是怎么用的就可以了。这是大型软件协作开发的理论基础。
API不仅仅是接口，类，方法，API可以是程序中任意暴露给使用者的事物。可以是文件结构，也可以是通信协议，还可以是模块组件。
1）可理解性；API是程序员之间的沟通方式，容易看懂使用是最重要的。
2）一致性；同一类API风格一致降低学习成本，不同版本的API功能要一致。
3）可见性；统一醒目的入口介绍API，最好有demo。
4）简单；给API分门别类，互不相关的API不要杂糅在一起。
5）向后兼容；新版尽可能不要修改或删除API的定义，也不要调整API的结构。
只公开必要的
1）可以构造子类对象返回，调用方无需关注子类类型。
2）可以返回缓存单例，而并不是每次都new一个新对象。
3）返回值可以是定义为带泛型的，构造函数不支持。
4）可以在对象构造前后做一些额外的事情。
1）Java原生只有public, protected, private, default四种访问级别，没有提供友元关键字来实现友元访问。
2）default访问级别为包级别访问，即同一个package之下的类能够互相访问。
3）如果要对类 C 实现友元访问，则 C 的所有方法都应该设置为default级别；然后在同一个包内定义一个 C 的代理类 DelegateC ，由 DelegateC 对外提供public的接口，内部调用 C 的方法来执行逻辑。
模块化架构
1）模块化架构是把复杂的单个应用程序分拆成互相之间有清晰依赖关系的模块，有利于软件的进化。
2）即使一个最简单的WEB应用，也可以拆成dal, biz, web三个模块，dal负责数据访问，biz负责业务逻辑，web负责请求控制与显示。每个模块都只公开必要的接口给外部模块访问，这样即使一个模块内部烂到骨子里，也不会腐蚀另一个干净的模块。
1）使用一个启动类，将被用到的模块中的服务类，实例化对象注册进来。缺点：硬编码方式不容易扩展。
2）依赖注入，采用配置文件或者注解的方式装配服务对象，如spring。缺点：除了需要用户主动装配外，基本完美。
3）Java标准的ServiceLoader机制。缺点：未提供完整的对象生命周期管理。
4) Netbeans 的Lookup。本质上是增强版的ServiceLoader，比如监听功能。
API 和 SPI
1）API主要是给外部客户调用的，一般会以代理的方式实现；SPI主要是给服务提供者扩展的，一般会以继承的方式实现。
2）新版本演进时，给API增加方法并不影响原有功能，而删减会；给SPI删减方法并不影响服务，而增加会；
1）不管是API还是SPI，最好区分核心还是非核心，方便90%的用户能够不受干扰，快速找到自己想要的。
2）设计时，识别API和SPI，放在不同的包内，区分对待更容易新版本的演进。
测试先行
1）用户使用API的方式千奇百怪，只有对每一个API提供单元测试，才能放心地变更API的内部实现。
2）单元测试不同于集成测试，如果遇到需要调用外部接口的情况，能mock尽量mock。
1）每一次的bug修复，都先补相应的测试用例来重现，再修复后验证。
API设计
1）API必须是漂亮的；首先得是正确的。
2）API必须是正确的：只需要在可期的时间规模内是正确的即可。
3）API必须是简单的；不能以牺牲功能为代价。
4）API必须是高性能的；优化性能万恶之源，跟其他所有特性相违背。
5）API必须是完全兼容的；评估完全兼容的代价，平衡资源。
1）API第一版本发布是最需要谨慎的，一旦发布即做出了向后兼容的承诺；
2）API的维护成本高昂，每一次升级都尽可能小心。
