我不懂Java，但我用c++做过。 也有人说这会让文字变得很长，很难读懂， 但我这样做过很多次:

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

这个更好:

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

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

我支持setter使用"this"返回。我不在乎它是否与豆子兼容。对我来说，如果有“=”表达式/语句是可以的，那么返回值的setter是可以的。

这个方案(双关语)，称为“流畅界面”，现在变得非常流行。还可以接受，但不是我的菜。

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

这通常被称为构建器模式或流畅接口。

它在Java API中也很常见:

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

总结:

它被称为“流畅接口”或“方法链接”。 这不是“标准”Java，尽管你现在看到的越来越多(在jQuery中工作得很好) 它违反了JavaBean规范，因此它将与各种工具和库分开，特别是JSP构建器和Spring。 它可能会阻止JVM通常会做的一些优化 一些人认为它能清理代码，另一些人认为它“可怕”

还有一些没有提到的要点:

This violates the principal that each function should do one (and only one) thing. You may or may not believe in this, but in Java I believe it works well. IDEs aren't going to generate these for you (by default). I finally, here's a real-world data point. I have had problems using a library built like this. Hibernate's query builder is an example of this in an existing library. Since Query's set* methods are returning queries, it's impossible to tell just by looking at the signature how to use it. For example: Query setWhatever(String what); It introduces an ambiguity: does the method modify the current object (your pattern) or, perhaps Query is really immutable (a very popular and valuable pattern), and the method is returning a new one. It just makes the library harder to use, and many programmers don't exploit this feature. If setters were setters, it would be clearer how to use it.

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