作用
有助于设计易于学习和使用的API。
如何做——谨慎地选择方法的名称
1.选择易于理解的，并且与同一个包中的其他名称风格一致的名称。
2.选择与大众认可的名称相一致的名称。
如何做——不要过于追求提供便利的方法
每个方法都应该尽其所能。
方法太多会使类难以学习、使用、文档化、测试和维护。
只有当一项操作被经常用到的时候，才考虑为它提供快捷方法。
如果不能肯定，还是不提供快捷方法为好。
如何做——避免过长的参数列表
目标是四个参数以内。
相同类型的长参数序列格外有害。
避免过长的参数列表——把方法分解成多个方法，每个方法只需要这些参数的一个子集
注意提升分解出的多个方法的正交性。
避免过长的参数列表——创建辅助类(helper class)，用来保存参数的分组
如果一个频繁出现的参数序列可以被看作是代表了某个独特的实体，建议使用这种方法。
避免过长的参数列表——从对象构建到方法调用都采用Builder模式
如果方法带有多个参数，尤其是当它们中有些是可选的时候，最好定义一个对象来表示所有参数，并允许客户端在这个对象上进行多次“setter”调用，每次调用都设置一个参数，或者设置一个较小的相关的集合。
一旦设置了需要的参数，客户端就调用对象的“执行(execute)”方法，它对参数进行最终的有效性检查，并执行实际的计算。
其他建议
优先使用接口而不是类定义参数类型。
对于boolean参数，要优先使用两个元素的枚举类型。
Thermometer.newInstance(TemperatureScala.CELSIUS)比Thermometer.newInstance(true)更有用，而且支持在未来对TemperatureScala对进行扩展。
枚举是可以有方法的，有时候这个特性也非常有用。
