让二传手返回“this”是不好的做法吗？

Question

让java中的setter返回“this”是个好主意还是坏主意？

public Employee setName(String name){
   this.name = name;
   return this;
}

这种模式很有用，因为你可以像这样链接设置器：

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

而不是这个：

Employee e = new Employee();
e.setName("Jack Sparrow");
...and so on...
list.add(e);

...但这有点违反标准约定。我想这可能是值得的，因为它可以让那个 setter 做一些其他有用的事情。我已经看到这种模式在某些地方使用过（例如 JMock、JPA），但它似乎并不常见，并且通常仅用于定义非常明确的 API，而这种模式无处不在。

更新：

我所描述的显然是正确的，但我真正想要的是一些关于这是否普遍可以接受的想法，以及是否存在任何陷阱或相关的最佳实践。我知道 Builder 模式，但它比我所描述的要复杂一些 - 正如 Josh Bloch 所描述的那样，有一个关联的静态 Builder 类用于对象创建。

Answer 1

这不是坏习惯。这是一种越来越普遍的做法。大多数语言不要求您处理返回的对象（如果您不想这样做），因此它不会改变“正常”的 setter 使用语法，但允许您将 setter 链接在一起。

这通常称为构建器模式或fluent interface。

在 Java API 中也很常见：

String s = new StringBuilder().append("testing ").append(1)
  .append(" 2 ").append(3).toString();

Answer 2

总结一下：

• 它被称为“流利的接口”或“方法链”。
• 这不是“标准”Java，尽管这些天你看到的越来越多（在 jQuery 中效果很好）
• 它违反了 JavaBean 规范，因此它会破坏各种工具和库，尤其是 JSP 构建器和 Spring。
• 它可能会阻止一些 JVM 通常会进行的优化
• 有些人认为它可以清理代码，有些人认为它“可怕”

还有几点没有提到：

• 这违反了每个函数应该做一件（并且只做一件）事情的原则。你可能相信也可能不相信，但在 Java 中我相信它运行良好。

• IDE 不会为您生成这些（默认情况下）。

• 最后，这是一个真实世界的数据点。我在使用这样构建的库时遇到了问题。 Hibernate 的查询构建器是现有库中的一个示例。由于 Query 的 set* 方法正在返回查询，因此仅通过查看签名无法判断如何使用它。例如：

  Query setWhatever(String what);
  

• 它引入了一个歧义：该方法是否修改了当前对象（您的模式），或者 Query 可能真的是不可变的（一种非常流行且有价值的模式），并且该方法正在返回一个新对象。它只是让库更难使用，而且许多程序员没有利用这个特性。如果 setter 是 setter，那么如何使用它会更清楚。

Answer 3

我更喜欢为此使用 'with' 方法：

public String getFoo() { return foo; }
public void setFoo(String foo) { this.foo = foo; }
public Employee withFoo(String foo) {
  setFoo(foo);
  return this;
}

因此：

list.add(new Employee().withName("Jack Sparrow")
                       .withId(1)
                       .withFoo("bacon!"));

警告：withX 语法通常用于为不可变对象提供“设置器”，因此这些方法的调用者可能合理地期望它们创建新对象而不是改变现有实例。也许更合理的措辞是这样的：

list.add(new Employee().chainsetName("Jack Sparrow")
                       .chainsetId(1)
                       .chainsetFoo("bacon!"));

使用 chainsetXyz() 命名约定，几乎每个人都应该感到高兴。

Answer 4

我不认为它有什么特别的问题，这只是风格问题。在以下情况下很有用：

• 您需要一次设置多个字段（包括在构造时）
• 您知道在编写代码时需要设置哪些字段，并且
• 您要设置的字段有许多不同的组合。

此方法的替代方法可能是：

1. 一个大型构造函数（缺点：您可能会传递大量空值或默认值，并且很难知道哪个值对应于什么）
2. 几个重载的构造函数（缺点：一旦你有多个，就会变得笨拙）
3. 工厂/静态方法（缺点：与重载的构造函数相同 - 一旦有多个，就会变得笨拙）

如果您一次只设置几个属性，我会说不值得返回“this”。如果您稍后决定返回其他内容，例如状态/成功指示器/消息，它肯定会失败。

Answer 5

如果您不想从 setter 返回 'this' 但又不想使用第二个选项，您可以使用以下语法来设置属性：

list.add(new Employee()
{{
    setName("Jack Sparrow");
    setId(1);
    setFoo("bacon!");
}});

顺便说一句，我认为它在 C# 中稍微干净一些：

list.Add(new Employee() {
    Name = "Jack Sparrow",
    Id = 1,
    Foo = "bacon!"
});

Answer 6

它不仅打破了 getter/setter 的约定，还打破了 Java 8 方法参考框架。 MyClass::setMyValue 是 BiConsumer<MyClass,MyValue>，myInstance::setMyValue 是 Consumer<MyValue>。如果你的设置器返回this，那么它不再是Consumer<MyValue> 的有效实例，而是Function<MyValue,MyClass>，并且将导致使用对这些设置器的方法引用（假设它们是无效方法）的任何操作中断。

Answer 7

我不懂 Java，但我用 C++ 做过。 其他人说它使行真的很长而且很难阅读， 但我已经这样做了很多次了：

list.add(new Employee()
    .setName("Jack Sparrow")
    .setId(1)
    .setFoo("bacon!"));

这样更好：

list.add(
    new Employee("Jack Sparrow")
    .Id(1)
    .foo("bacon!"));

至少，我认为。但是，如果您愿意，欢迎您对我投反对票并称我为糟糕的程序员。而且我不知道你是否被允许在 Java 中这样做。

Answer 8

至少理论上，它可以通过在调用之间设置错误的依赖关系来破坏JVM的优化机制。

本应是语法糖，但实际上会在超智能Java 43的虚拟机中产生副作用。

这就是我投反对票的原因，不要使用它。

Answer 9

这根本不是一个坏习惯。但与JavaBeans Spec不兼容。

并且有很多规范取决于这些标准访问器。

你总是可以让它们相互共存。

public class Some {
    public String getValue() { // JavaBeans
        return value;
    }
    public void setValue(final String value) { // JavaBeans
        this.value = value;
    }
    public String value() { // simple
        return getValue();
    }
    public Some value(final String value) { // fluent/chaining
        setValue(value);
        return this;
    }
    private String value;
}

现在我们可以一起使用它们了。

new Some().value("some").getValue();

这是不可变对象的另一个版本。

public class Some {

    public static class Builder {

        public Some build() { return new Some(value); }

        public Builder value(final String value) {
            this.value = value;
            return this;
        }

        private String value;
    }

    private Some(final String value) {
        super();
        this.value = value;
    }

    public String getValue() { return value; }

    public String value() { return getValue();}

    private final String value;
}

现在我们可以这样做了。

new Some.Builder().value("value").build().getValue();

Answer 10

因为它不返回 void，所以它不再是一个有效的 JavaBean 属性设置器。如果您是世界上使用可视化“Bean Builder”工具的七个人之一，或者是使用 JSP-bean-setProperty 元素的 17 个人之一，这可能很重要。

Answer 11

这种称为“流畅界面”的方案（双关语）现在变得非常流行。这是可以接受的，但这不是我真正喜欢的茶。

Answer 12

如果您在整个应用程序中使用相同的约定，那似乎没问题。

另一方面，如果您的应用程序的现有部分使用标准约定，我会坚持它并将构建器添加到更复杂的类中

public class NutritionalFacts {
    private final int sodium;
    private final int fat;
    private final int carbo;

    public int getSodium(){
        return sodium;
    }

    public int getfat(){
        return fat;
    }

    public int getCarbo(){
        return carbo;
    }

    public static class Builder {
        private int sodium;
        private int fat;
        private int carbo;

        public Builder sodium(int s) {
            this.sodium = s;
            return this;
        }

        public Builder fat(int f) {
            this.fat = f;
            return this;
        }

        public Builder carbo(int c) {
            this.carbo = c;
            return this;
        }

        public NutritionalFacts build() {
            return new NutritionalFacts(this);
        }
    }

    private NutritionalFacts(Builder b) {
        this.sodium = b.sodium;
        this.fat = b.fat;
        this.carbo = b.carbo;
    }
}

Answer 13

Paulo Abrantes 提供了另一种使 JavaBean 设置器流畅的方法：为每个 JavaBean 定义一个内部构建器类。如果您使用的工具会被返回值的设置器弄得一头雾水，那么 Paulo 的模式可能会有所帮助。

Answer 14

我赞成二传手拥有“this”回报。我不在乎它是否不符合 bean。对我来说，如果可以使用“=”表达式/语句，那么返回值的设置器就可以了。

Answer 15

我以前更喜欢这种方法，但我决定不这样做。

原因：

• 可读性。将每个 setFoo() 放在单独的行上会使代码更具可读性。您阅读代码的次数通常比编写一次的次数要多得多。
• 副作用：setFoo() 应该只设置字段 foo，没有别的。返回这是一个额外的“那是什么”。

我看到的 Builder 模式没有使用 setFoo(foo).setBar(bar) 约定，而是更多的 foo(foo).bar(bar)。也许正是因为这些原因。

一如既往，这是一个品味问题。我只是喜欢“最少惊喜”的方法。

Answer 16

是的，我认为这是个好主意。

如果我可以添加一些东西，这个问题呢：

class People
{
    private String name;
    public People setName(String name)
    {
        this.name = name;
        return this;
    }
}

class Friend extends People
{
    private String nickName;
    public Friend setNickName(String nickName)
    {
        this.nickName = nickName;
        return this;
    }
}

这将起作用：

new Friend().setNickName("Bart").setName("Barthelemy");

Eclipse 不会接受这个！ ：

new Friend().setName("Barthelemy").setNickName("Bart");

这是因为 setName() 返回的是 People 而不是 Friend，并且没有 PeoplesetNickName。

我们如何编写 setter 来返回 SELF 类而不是类的名称？

这样的事情就可以了（如果 SELF 关键字存在的话）。这到底存在吗？

class People
{
    private String name;
    public SELF setName(String name)
    {
        this.name = name;
        return this;
    }
}

Answer 17

这种特殊的模式称为方法链。 Wikipedia link，这有更多的解释和例子，说明它是如何在各种编程语言中完成的。

P.S：只是想把它留在这里，因为我正在寻找具体的名字。

Answer 18

第一眼：“可怕！”。

进一步思考

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

实际上比

更不容易出错

Employee anEmployee = new Employee();
anEmployee.setName("xxx");
...
list.add(anEmployee);

非常有趣。在工具包中添加想法...

Answer 19

一般来说这是一个很好的做法，但是你可能需要对 set 类型的函数使用 Boolean 类型来确定操作是否成功完成，这也是一种方法。总的来说，没有教条说这是好还是床，当然是从情况来的。

Answer 20

来自声明

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

我看到了两件事

1) 无意义的陈述。 2) 缺乏可读性。

Answer 21

这可能不太可读

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!")); 

或者这个

list.add(new Employee()
          .setName("Jack Sparrow")
          .setId(1)
          .setFoo("bacon!")); 

这比以下更具可读性：

Employee employee = new Employee();
employee.setName("Jack Sparrow")
employee.setId(1)
employee.setFoo("bacon!")); 
list.add(employee); 

Answer 22

我已经做了很长一段时间的设置器，唯一真正的问题是坚持使用严格的 getPropertyDescriptors 来获取 bean 读取器/写入器 bean 访问器的库。在这些情况下，您的 java“bean”将没有您期望的写入器。

例如，我还没有确定地对其进行测试，但如果 Jackson 在从 json/maps 创建 java 对象时不会将它们识别为 setter，我不会感到惊讶。我希望我在这个问题上错了（我会尽快测试它）。

事实上，我正在开发一个以 SQL 为中心的轻量级 ORM，我必须在 getPropertyDescriptors 之外添加一些代码，以将其添加到可识别的 setter 以返回它。

Answer 23

很久以前的回答，但我的两分钱......没关系。我希望这个流畅的界面能被更多地使用。

重复“工厂”变量不会在下面添加更多信息：

ProxyFactory factory = new ProxyFactory();
factory.setSuperclass(Foo.class);
factory.setFilter(new MethodFilter() { ...

这更干净，恕我直言：

ProxyFactory factory = new ProxyFactory()
.setSuperclass(Properties.class);
.setFilter(new MethodFilter() { ...

当然，正如已经提到的答案之一，Java API 必须进行调整才能在某些情况下正确执行此操作，例如继承和工具。

Answer 24

如果可用，最好使用其他语言结构。例如，在 Kotlin 中，您可以使用 with、apply 或 let。如果使用这种方法，您将真正需要从您的 setter 返回一个实例。

这种方法允许您的客户端代码：

• 与返回类型无关
• 更易于维护
• 避免编译器副作用

这里有一些例子。

val employee = Employee().apply {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
with(employee) {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
employee.let {
   it.name = "Jack Sparrow"
   it.id = 1
   it.foo = "bacon"
}

Answer 25

如果我正在编写 API，我会使用“return this”来设置只会设置一次的值。如果我有任何其他用户应该能够更改的值，我会改用标准的 void setter。

但是，在我看来，这确实是一个偏好问题，并且链式设置器看起来确实很酷。

Answer 26

我同意所有声称这违反了 JavaBeans 规范的海报。有理由保留这一点，但我也觉得使用这个 Builder 模式（被暗示）有它的位置；只要不是到处都用，应该是可以接受的。对我来说，“It's Place”是调用“build()”方法的终点。

当然还有其他设置所有这些东西的方法，但这里的优点是它避免了 1) 多参数公共构造函数和 2) 部分指定的对象。在这里，您让构建器收集所需的内容，然后在最后调用它的“build()”，这样可以确保不构造部分指定的对象，因为该操作可以被赋予不公开的可见性。另一种选择是“参数对象”，但恕我直言，这只是将问题推回到了一个层次。

我不喜欢多参数构造函数，因为它们更有可能传入许多相同类型的参数，这可以更容易地将错误的参数传递给参数。我不喜欢使用大量的设置器，因为该对象可以在完全配置之前使用。此外，使用“build()”方法可以更好地实现基于先前选择的默认值的概念。

简而言之，如果使用得当，我认为这是一个很好的做法。

Answer 27

坏习惯： 二传手 一个吸气剂得到

如何显式声明一个方法，为 U 做它

setPropertyFromParams(array $hashParamList) { ... }