Java方法中的参数太多，第5部分：方法命名

在上一篇文章（有关处理Java方法中过多参数的系列文章的第4部分）中，我将方法重载视为一种向客户提供需要较少参数的方法版本或构造函数的方法。我描述了该方法的一些缺点，并建议从方法重载中摆脱出来以使用不同名称的方法至少可以部分解决这些缺点。在本文中，我将更深入地探讨如何使用仔细的方法命名（包括构造方法）来删除冗长的参数列表并避免方法重载的某些问题。

从减少方法和构造函数调用中所需的参数数量的角度来看，与方法重载相关的一些最重要的问题围绕着对大量参数可以重载相同方法名多少次的限制，尤其是在某些情况下的参数共享相同的数据类型。例如，如果我有一个具有三个String属性的类，并且想编写三个构造函数以分别仅接受这些属性之一，那么我真的不能通过方法重载来做到这一点。如果我尝试过，则必须将接受单个String的构造函数用于三个属性之一，并且只有Javadoc注释才能解释单参数构造函数设置的三个属性中的哪个。摆脱对所有方法和构造方法使用相同名称的限制，可以使代码在预期和假定参数方面更具表现力。

下面的代码清单包含各种方法的一些示例，这些方法要求一个独立的类（不是Person类）提供Person的实例（在我以前的文章中引用了太多的Java参数，该类引用了该类）。这些方法的名称很长，描述了有关参数预期的内容。这意味着Javadoc注释中需要描述的内容更少，客户端更容易理解方法的调用，并且与方法重载相比，可以支持更多参数的可能性和排列。

命名方法的示例以描述其功能

public Person createPersonWithFirstAndLastNameOnly(final String firstName, final String lastName){// implementation goes here ...}public Person createEmployedHomeOwningFemale(final FullName name, final Address address){// implementation goes here ...}public Person createEmployedHomeOwningMale(final FullName name, final Address address){// implementation goes here ...}public Person createUnemployedHomeOwningFemale(final FullName name, final Address address){// implementation goes here ...}public Person createEmployedRentingMale(final FullName name, final Address address){// implementation goes here ...}

上面代码中显示的较长的方法名称具有描述性，可为客户端提供一个良好的起点，让他们知道要提供哪些参数。当然，我可以编写更多类似上述方法的方法来介绍参数的各种排列，但是我列出的小集合可以说明这一点。注意，在这些代码示例中，我还使用了参数对象（在我的参数对象文章中定义的FullName和Address ）来进一步减少参数的数量。

我上面的代码示例演示了为实例方法提供不同的描述性名称，以暗示要传递的参数，甚至在某些情况下还暗示不需要提供哪些参数，因为它们隐含在方法名称中。 Java的新手可能会认为此方法不能与对象实例化/构造一起使用，因为Java类构造函数必须使用与该类相同的名称来命名。这意味着只能基于方法签名重载构造函数。幸运的是， Josh Bloch在Effective Java的两个版本的第一篇中都谈到了这一问题。正如Bloch在此处所述，我们可以采用静态初始化工厂方法来提供类的实例。 Bloch在第1项中引用的好处之一是能够按我们认为合适的方式命名这些方法。

下一个代码清单演示了这些静态初始化工厂的功能。当我实现这些时，我喜欢实现仅由静态初始化工厂调用的一个或很少数量的private构造函数（无法通过外部类实例化）。这使我可以将构造函数的方法签名留给潜在的不足，因为仅我的类必须使用它，而其他人使用的静态初始化工厂更易于使用，并且隐藏了许多参数构造函数的丑陋之处。更具体地说，如果构造函数对可选参数采用null，则可以编写各种静态初始化工厂，以便我的客户端不需要传递null，但我的工厂方法可以将null传递给构造函数。简而言之，静态初始化工厂方法使我能够为客户端提供更简洁，更愉悦的界面，并在类的内部隐藏丑陋之处。由于无法用解释性细节给它们命名，因此我不能轻易地直接为它提供多个构造函数。这些静态初始化方法的另一个优点是，如果需要，我可以让它们接受“原始”类型并将其内置到自定义类型和参数对象中。所有这些情况在下一个代码清单中显示。

静态初始化工厂展示

/*** Parameterized constructor can be private because only my internal builder* needs to call me to provide an instance to clients.* * @param newName Name of this person.* @param newAddress Address of this person.* @param newGender Gender of this person.* @param newEmployment Employment status of this person.* @param newHomeOwner Home ownership status of this person.*/private Person(final FullName newName, final Address newAddress,final Gender newGender, final EmploymentStatus newEmployment,final HomeownerStatus newHomeOwner){this.name = newName;this.address = newAddress;this.gender = newGender;this.employment = newEmployment;this.homeOwnerStatus = newHomeOwner;}public static Person createInstanceWithNameAndAddressOnly(final FullName newName, final Address newAddress){return new Person(newName, newAddress, null, null, null);}public static Person createEmployedHomeOwningFemale(final FullName newName, final Address newAddress){return new Person(newName, newAddress, Gender.FEMALE, EmploymentStatus.EMPLOYED, HomeownerStatus.HOME_OWNER);}public static Person createEmployedHomeowningMale(final FullName newName, final Address newAddress){return new Person(newName, newAddress, Gender.MALE, EmploymentStatus.EMPLOYED, HomeownerStatus.HOME_OWNER);}public static Person createUnemployedMaleRenter(final FullName newName, final Address newAddress){return new Person(newName, newAddress, Gender.MALE, EmploymentStatus.NOT_EMPLOYED, HomeownerStatus.RENTER);}public static Person createPersonWithFirstNameLastNameAndAddress(final Name newFirstName, final Name newLastName, final Address newAddress){return new Person(new FullName.FullNameBuilder(newLastName, newFirstName).createFullName(),newAddress, null, null, null);}public static Person createPersonWithFirstNameLastNameAndAddress(final String newFirstName, final String newLastName, final Address newAddress){return new Person(new FullName.FullNameBuilder(new Name(newLastName), new Name(newFirstName)).createFullName(),newAddress, null, null, null);}

如以上示例所示，这些方法的客户可以使用可读性强的方法，而不必担心提供大量参数。前面的代码清单中的最后两个方法是将方法重载与静态初始化工厂方法结合在一起的示例。

优势与优势

使用适当命名的方法（在这些方法的名称中包含有关预期参数和隐含参数的信息）会带来一些优于简单方法/构造函数重载的优点。由于可以根据每种方法的预期和假设自定义方法的名称，因此调用代码的意图更加明确。如上面的示例所示，这些方法可能意味着不需要显式提供哪些参数，因为它们被假定为该方法的一部分（并且意图是通过方法的名称而不是通过Javadoc进行通信的）。

我在这里没有明确地关注它，但是与简单的方法重载相比，精心选择的方法名称的另一个优点是能够在方法名称中包含单元或其他上下文信息。例如，我可以提供setWholeLengthInMeters(int)和setFractionalLengthInFeet(double)方法，而不是使用接受int和double setLength()方法。

成本与劣势

使用名称不同的实例方法和静态初始化工厂方法肯定比方法重载提供了一些优势，但是不幸的是，从参数减少的角度来看，仍然具有方法重载的一些缺点。不同名称的方法与重载方法共享的一个缺点是可能必须编写许多方法来支持可能使用的参数的各种组合和排列。如果在以上示例中仅针对性别，房主身份和就业身份的每种组合编写了一种方法，则将需要八个方法（第2到第3次幂）。如果任何一个单独的参数可以具有2种以上的可能性，则命名方法的不同组合的数量仅用于处理该增加的不同可能性。当然，没有有限可能性的参数不能为每个可能的值编写方法，因此必须传入而不是假定。

尽管描述性很强的方法名称很容易阅读，但潜在的名称过多可能会降低总体可读性，因为客户端在调用类时必须经过一长串方法。同样，某些人可能不喜欢长的方法名称以及他们在屏幕上占用大量空间。我个人并不介意长名称，因为我认为它们提供的可读性值得在屏幕上添加其他文本。 IDE和代码完成功能意味着很少有人再输入这些名称，并且开发人员使用了很多监视器，这使得长方法名称的问题不再那么麻烦。