ITEM 51: DESIGN METHOD SIGNATURES CAREFULLY
  本章节是一个API设计提示的集合，它们将有助于使您的API更易于学习和使用，并减少出错的可能性。
  仔细选择方法名。名称应始终遵循标准命名约定(item 68)。您的主要目标应该是选择易于理解的、与同一包中的其他名称一致的名称。你的第二个目标应该是选择与广泛共识相一致的名字。避免长方法名。如果有疑问，可以参考Java库api。尽管存在大量的矛盾——考虑到这些库的规模和范围，这是不可避免的——但也存在相当多的共识。
  不要提供太过方便的方法。每一种方法都应该“尽其所能”。太多的方法使类难于学习、使用、记录、测试和维护。对于接口来说更是如此，太多的方法使实现者和用户的生活变得复杂。对于类或接口支持的每个操作，都要提供一个全功能的方法。只有在经常使用时才考虑提供“速记”。当你有疑问时，就把它排除在外。
  避免长参数列表。设定四个或更少的参数。大多数程序员记不住更长的参数列表。如果您的许多方法超过了这个限制，那么如果没有对其文档的不断引用，您的API就无法使用。现代的 IDE 会有所帮助，但是使用简短的参数列表仍然更好。同类型参数的长序列尤其有害。用户不仅不能记住参数的顺序，而且当他们不小心转置参数时，他们的程序仍然可以编译和运行。他们只是不会按照作者的意图去做。
  有三种技术可以缩短过长的参数列表。一种是将方法分解为多个方法，每个方法只需要参数的一个子集。但这可能导致太多的方法，但是它也可以通过增加正交性来帮助减少方法数量。例如，考虑 java.util.List。它没有提供查找子列表中元素的第一个或最后一个索引的方法，这两个方法都需要三个参数。相反，它提供了子列表方法，该方法接受两个参数并返回子列表的视图。该方法可以与 indexOf 或 lastIndexOf 方法相结合，每个方法都有一个单独的参数，从而产生所需的功能。此外，可以将子列表方法与在列表实例上操作的任何方法组合使用，以执行子列表上的任意计算。这样设计的 API 具有非常高的功率-重量比。
  缩短长参数列表的第二种技术是创建辅助类来保存参数组。通常这些帮助类是静态成员类(item 24)。如果经常出现的参数序列表示一些不同的实体，则推荐使用此技术。例如，假设您正在编写一个表示纸牌游戏的类，并且您发现自己不断地传递一个由表示纸牌等级和花色的两个参数组成的序列。如果您添加一个助手类来表示一张卡片，并使用助手类的单个参数替换参数序列的每次出现，那么您的 API 可能会受益。
  结合前两个方面的第三种技术是将Builder模式(项目2)从对象构造调整为方法调用。如果你有一个方法与许多参数,特别是其中一些是可选的,它可以有利于定义一个对象,代表所有的参数,并允许客户端进行多个“setter”调用这个对象,每一个都设置一个参数或小,相关的组。一旦设置了所需的参数，客户机将调用对象的“execute”方法，该方法对参数进行最后的有效性检查并执行实际的计算。
  对于参数类型，优先选择接口而不是类(iem 64)。如果存在定义参数的适当接口，请使用它来支持实现该接口的类。例如，没有理由编写一个在输入端使用 HashMap 的方法——而是使用Map。这允许您传入 HashMap、TreeMap、ConcurrentHashMap、TreeMap 的子映射或任何尚未编写的映射实现。通过使用类而不是接口，您可以将客户端限制在特定的实现中，如果输入数据碰巧以其他形式存在，则会强制执行不必要的、可能开销很大的复制操作。
  宁可使用双元素enum类型，也不要使用布尔参数，除非从方法名中可以清楚地看出布尔的含义。枚举使你的代码更容易读和写。此外，它们使以后添加更多选项变得很容易。例如，你可能有一个温度计类型与静态工厂，采取这个枚举:
public enum TemperatureScale { FAHRENHEIT, CELSIUS }
  不仅 Thermometer.newInstance(TemperatureScale.CELSIUS) 更有意义，而且在将来的版本中，你可以在温标中添加开尔文，而不必在温度计中添加新的静态工厂。此外，您还可以将温标依赖项重构为 enum常量(item 34)上的方法。例如，每个比例常数都有一个方法，该方法取一个双值并将其转换为摄氏度。