让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已经有一段时间了,唯一真正的问题是库坚持使用严格的getPropertyDescriptors来获得bean读取器/写入器bean访问器。在这些情况下,您的java“bean”将没有您所期望的写入器。

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

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

其他回答

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

这个方案(双关语),称为“流畅界面”,现在变得非常流行。还可以接受,但不是我的菜。

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

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

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

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

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

它在Java API中也很常见:

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

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