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

我过去更喜欢这种方法，但我已经决定不这么做了。

原因:

可读性。将每个setFoo()放在单独的行上可以使代码更具可读性。通常情况下，您阅读代码的次数要比编写代码的次数多得多。 副作用:setFoo()应该只设置字段foo，没有其他。返回this是一个额外的“WHAT was that”。

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

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

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

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

它在Java API中也很常见:

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

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

例如，我还没有测试它的确定，但我不会感到惊讶，杰克逊不会识别这些设置时，从json/maps创建java对象。我希望我在这一点上是错的(我很快就会测试它)。

事实上，我正在开发一个轻量级的以SQL为中心的ORM，我必须在getPropertyDescriptors之外添加一些代码来识别返回此的设置器。

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

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

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;
    }
}

总结:

它被称为“流畅接口”或“方法链接”。 这不是“标准”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.