让setter返回"this"是不好的做法吗?

让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类。

当前回答

从声明中

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

我看到两件事

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

其他回答

我不懂Java，但我用c++做过。也有人说这会让文字变得很长，很难读懂，但我这样做过很多次:

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

这个更好:

list.add(
    new Employee("Jack Sparrow")
    .Id(1)
    .foo("bacon!"));

至少我是这么认为的。但如果你愿意，欢迎你给我投反对票，称我为糟糕的程序员。我不知道Java中是否允许这样做。

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

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

它在Java API中也很常见:

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

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

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

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

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

很久以前的答案，但我的两分钱…这是很好的。我希望这个流畅的界面被更多地使用。

重复'factory'变量不会在下面添加更多信息:

ProxyFactory factory = new ProxyFactory();
factory.setSuperclass(Foo.class);
factory.setFilter(new MethodFilter() { ...

恕我直言，这个更干净:

ProxyFactory factory = new ProxyFactory()
.setSuperclass(Properties.class);
.setFilter(new MethodFilter() { ...

当然，正如前面提到的答案之一，Java API必须进行调整，以便在某些情况下(如继承和工具)正确执行此操作。

推荐文章