建议：谨慎设计方法签名。

以下设计技巧将有助于使你的API更易于学习和使用，并且比较不容易出错。

谨慎的选择方法的名称

方法的名称应该始终遵循标准的命名习惯。首要目标应该是选择易于理解的，并且与同一个包中的其他名称风格一致的名称。第二个目标应该是选择与大众认可的名称（如果存在的话）相一致的名称。如果还有以为呢，请参考Java类库的API。尽管Java类库的API中也有大量不一致的地方，考虑到这些Java类库的规模和范围，这是不可避免地，但他还是得到了相当程序的认可。

不要过于追求提供便利的方法

每个方法都应该尽其所能。方法太多会使类难以学习、使用、文档化、测试和维护。对于接口而言，这无意识正确的，方法太多会使接口实现者和接口用户的工作变得复杂起来。对于类和接口所支持的每个动作，都提供一个功能齐全的方法。只有当一项操作被经常用到的时候，才考虑为他提供快捷方式。如果不能确定，还是不提供快捷为好。

避免过长的参数列表

目标是四个参数，或者更少。大多数程序员都无法记住更长的参数列表。如果你编写的许多方法都超过了这个限制，你的API就不太便于使用，除非用户不停的参考他的文档。现代IDE会有所帮助，但最好还是使用简单的参数列表。相同类型的长参数序列格外有害。API的用户不仅无法记住参数的顺序，而且，当他们不小心弄错了参数顺序时，他们的程序仍然可以编译和运行，只不过这些程序不会按照作者的意图进行工作。有三种方法可以缩短过长的参数列表：

• 把方法分解成多个方法，每个方法只需要这些参数的一个子集。如果不小心，这样做会导致方法过多。但是通过提升他们的正交性，还可以减少方法的数目。
• 创建辅助类，用来保存参数的分组。这些辅助类一般为静态成员类。如果一个频繁出现的参数序列可以被看做是代表了某个独特的实体，则建议使用这种方法。
• 结合了前两种方法特征的第三种方法是，从对象构建到方法调用都采用Builder模式。

对于参数类型，要优先使用接口而不是类

只要有适当的接口可用来定义参数，就优先使用这个接口，而不是使用实现该接口的类。如果使用的是类而不是接口，则限制了客户端只能传入特定的实现，如果碰巧输入的数据是以其他的形式存在，就会导致不必要的、可能非常昂贵的拷贝操作。

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

他使代码更易于阅读和编写，尤其当你在使用支持自动完成功能的IDE的时候。他也使以后更易于添加更多的选项。