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

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

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

它在Java API中也很常见:

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

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

原因:

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

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

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

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

这可能可读性较差

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

或者这个

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

这比:

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

我制作setter已经有一段时间了，唯一真正的问题是库坚持使用严格的getPropertyDescriptors来获得bean读取器/写入器bean访问器。在这些情况下，您的java“bean”将没有您所期望的写入器。

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

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