第一眼看到:“可怕!”

进一步思考

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

实际上更不容易出错

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

非常有趣。添加想法toolbag…

一般来说，这是一个很好的实践，但是你可能需要使用布尔类型来确定操作是否成功完成，这也是一种方法。一般来说，没有教条说这是好的还是床上的，它当然来自于情况。

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

您需要一次设置多个字段(包括在构建时) 您知道在编写代码时需要设置哪些字段 对于想要设置的字段，有许多不同的组合。

这种方法的替代方法可能是:

一个mega构造函数(缺点:你可能会传递很多空值或默认值，并且很难知道哪个值对应什么) 几个重载的构造函数(缺点:一旦你有多个构造函数，就会变得笨拙) 工厂方法/静态方法(缺点:与重载构造函数相同——一旦超过几个就会变得笨拙)

如果你一次只设置几个属性，我会说不值得返回this。如果您稍后决定返回其他内容，例如状态/成功指示符/消息，那么它肯定会崩溃。

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

原因:

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

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

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

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

这一点也不坏。但是它与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();