Question

方法签名是方法声明的一部分。它是方法名称和参数列表的组合。

因此，我只想传递一个构成所有参数的请求对象，而不是指定参数列表。对于所有方法可能都不是这样，但是想要在任何可能的地方尝试。

比如说

public void setMapReference(int xCoordinate, int yCoordinate)
{
  //method code
}

也可以写成

public void setMapReference(Point point)
{
  //method code
}

class Point {
  int xCoordinate;
  int yCoordinate;
  boolean isValidPoint();
}

但是调用者可能会因为他不知道参数而感到困惑。!!

这是一个好习惯吗？

Answer 1

我不会“在任何可能的地方”这样做 - 但这通常是一个好主意，是的。基本上，问问自己参数本身是否构成一个连贯的单一实体：将它们混合在一起并将它们视为单个“事物”是否有意义？如果是这样，封装它们听起来是个好主意。如果存在明显的行为，那个“事物”可以承担责任，以避免代码生活在已经承担其他责任的类中，那就更好了。

编辑：请注意，我不会让Point类型具有您显示的包访问字段：我会像往常一样使它们成为具有属性的私有字段。如果可能的话，我会尝试让它变得不可变。

Answer 2

如果只有2个参数，请不要管它。对象参数可能会导致复杂，也许您甚至需要对象参数的防御性副本。

另一方面，大多数程序员都记不起超过 3 的参数，如果参数中有相同的数据类型，那么程序员就会更糟糕，而且容易出错。在这种情况下，使用object参数是个好主意。

Answer 3

问题Building big, immutable objects without using constructors having long parameter lists的一些答案也可能与此相关（如果您处理方法或构造函数并不重要，毕竟构造函数只是一种特殊方法）。

将一个请求对象作为Method Signature参数，构成所有必需参数

3 个答案: