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

它被认为是语法糖，但实际上会在超级智能的Java 43虚拟机中产生副作用。

这就是为什么我投反对票，不要使用它。

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

它被认为是语法糖，但实际上会在超级智能的Java 43虚拟机中产生副作用。

这就是为什么我投反对票，不要使用它。

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

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

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

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

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

原因:

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

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

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

如果你不想从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!"
});