让java中的setter返回“this”是好还是坏?

public Employee setName(String name){
   this.name = name;
   return this;
}

这个模式很有用,因为你可以像这样设置链:

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

而不是这样:

Employee e = new Employee();
e.setName("Jack Sparrow");
...and so on...
list.add(e);

...但这有点违背标准惯例。我认为这是值得的因为它可以让setter做一些其他有用的事情。我曾在一些地方看到过这种模式(例如JMock、JPA),但它似乎并不常见,而且通常只用于定义良好的api,在这些api中这种模式随处可见。

更新:

我所描述的显然是有效的,但我真正想要的是一些关于这是否被普遍接受的想法,以及是否存在任何陷阱或相关的最佳实践。我知道Builder模式,但它比我所描述的要复杂一些——正如Josh Bloch所描述的,有一个用于对象创建的相关静态Builder类。


当前回答

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

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

它在Java API中也很常见:

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

其他回答

坏习惯: setter集 getter get

如果显式地声明一个方法,为U

setPropertyFromParams(array $hashParamList) { ... }

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

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

它在Java API中也很常见:

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

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

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

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

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

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

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

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