如果可用，最好使用其他语言结构。例如，在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"
}

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

如果我能补充点什么，关于这个问题:

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

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

原因:

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

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

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

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

从声明中

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

我看到两件事

1)毫无意义的话。 2)缺乏可读性。

它不仅打破了getter /setter的惯例，还打破了Java 8方法参考框架。MyClass::setMyValue是一个BiConsumer<MyClass,MyValue>， myInstance::setMyValue是一个Consumer<MyValue>。如果你让你的setter返回这个，那么它就不再是Consumer<MyValue>的有效实例，而是Function<MyValue,MyClass>，并且会导致任何使用这些setter的方法引用(假设它们是void方法)的事情中断。