作用

有助于设计易于学习和使用的API。

如何做——谨慎地选择方法的名称

1.选择易于理解的，并且与同一个包中的其他名称风格一致的名称。

2.选择与大众认可的名称相一致的名称。

如何做——不要过于追求提供便利的方法

每个方法都应该尽其所能。

方法太多会使类难以学习、使用、文档化、测试和维护。

只有当一项操作被经常用到的时候，才考虑为它提供快捷方法。

如果不能肯定，还是不提供快捷方法为好。

如何做——避免过长的参数列表

目标是四个参数以内。

相同类型的长参数序列格外有害。

避免过长的参数列表——把方法分解成多个方法，每个方法只需要这些参数的一个子集

注意提升分解出的多个方法的正交性。

避免过长的参数列表——创建辅助类(helper class)，用来保存参数的分组

如果一个频繁出现的参数序列可以被看作是代表了某个独特的实体，建议使用这种方法。

避免过长的参数列表——从对象构建到方法调用都采用Builder模式

如果方法带有多个参数，尤其是当它们中有些是可选的时候，最好定义一个对象来表示所有参数，并允许客户端在这个对象上进行多次“setter”调用，每次调用都设置一个参数，或者设置一个较小的相关的集合。

一旦设置了需要的参数，客户端就调用对象的“执行(execute)”方法，它对参数进行最终的有效性检查，并执行实际的计算。

其他建议

优先使用接口而不是类定义参数类型。

对于boolean参数，要优先使用两个元素的枚举类型。

Thermometer.newInstance(TemperatureScala.CELSIUS)比Thermometer.newInstance(true)更有用，而且支持在未来对TemperatureScala对进行扩展。

枚举是可以有方法的，有时候这个特性也非常有用。