让二传手返回“ 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);

...但是有点违反标准惯例。我想这可能是值得的，因为它可以使设置者做其他有用的事情。我已经看到此模式在某些地方使用过（例如JMock，JPA），但这似乎并不常见，并且仅用于定义非常明确的API，该模式随处可见。

更新：

我所描述的内容显然是有效的，但是我真正要寻找的是一些关于是否可以普遍接受以及是否存在陷阱或相关最佳实践的想法。我知道Builder模式，但是它比我描述的要复杂得多-正如Josh Bloch所描述的那样，有一个关联的静态Builder类用于对象创建。

我不认为这有什么特别的问题，这只是风格问题。在以下情况下很有用：

• 您需要一次设置多个字段（包括在构造中）
• 您知道在编写代码时需要设置哪些字段，以及
• 您要为哪些字段设置许多不同的组合。

此方法的替代方法可能是：

1. 一个大型构造函数（缺点：您可能传递大量的null或默认值，并且很难知道哪个值对应什么）
2. 几个重载的构造函数（缺点：一旦有多个，就会变得笨拙）
3. 工厂/静态方法（缺点：与重载的构造函数相同-一旦存在过多，就会变得笨拙）

如果您一次只设置几个属性，我会说不值得返回“ this”。如果您以后决定返回其他内容，例如状态/成功指示符/消息，它肯定会下降。

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

这通常称为构建器模式或流利的界面。

在Java API中也很常见：

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

总结一下：

• 它称为“流利接口”或“方法链接”。
• 这不是“标准” Java，尽管最近您确实看到了更多（在jQuery中效果很好）
• 它违反了JavaBean规范，因此将与各种工具和库一起破坏，尤其是JSP构建器和Spring。
• 它可能会阻止JVM通常会进行的某些优化
• 有些人认为它清理了代码，另一些人认为它“很糟糕”

未提及的其他几点：

• 这违反了每个函数都应该做一件（并且只能一件）事情的原则。您可能会或可能不会相信这一点，但是我相信在Java中它会很好地工作。

• IDE不会为您生成这些（默认情况下）。

• 我终于有了一个真实的数据点。使用这样的库时，我遇到了问题。Hibernate的查询生成器是现有库中的一个示例。由于Query的set *方法正在返回查询，因此仅通过查看签名来说明如何使用是不可能的。例如：

  Query setWhatever(String what);

• 它引入了一个歧义：方法是修改当前对象（您的模式），还是Query确实是不可变的（一种非常流行且有价值的模式），并且该方法返回了一个新对象。这只会使该库更难使用，并且许多程序员不会利用此功能。如果二传手是二传手，那么使用起来会更清楚。

我更喜欢使用'with'方法：

public String getFoo() { return foo; }
public void setFoo(String foo) { this.foo = foo; }
public Employee withFoo(String foo) {
  setFoo(foo);
  return this;
}

从而：

list.add(new Employee().withName("Jack Sparrow")
                       .withId(1)
                       .withFoo("bacon!"));

警告：此withX语法通常用于为不可变对象提供“设置器”，因此这些方法的调用者可能会合理地期望它们创建新对象，而不是改变现有实例。也许更合理的措辞应该是这样的：

list.add(new Employee().chainsetName("Jack Sparrow")
                       .chainsetId(1)
                       .chainsetFoo("bacon!"));

使用chainsetXyz（）命名约定，几乎每个人都应该感到高兴。

如果您不想'this'从设置器中返回但又不想使用第二个选项，则可以使用以下语法来设置属性：

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

顺便说一句，我认为它在C＃中稍微干净一些：

list.Add(new Employee() {
    Name = "Jack Sparrow",
    Id = 1,
    Foo = "bacon!"
});

它不仅打破了getters / setter的约定，而且打破了Java 8方法参考框架。MyClass::setMyValue是BiConsumer<MyClass,MyValue>，并且myInstance::setMyValue是Consumer<MyValue>。如果您有setter return this，则它不再是的有效实例Consumer<MyValue>，而是一个Function<MyValue,MyClass>，并且会导致使用对这些setter的方法引用（假设它们是无效方法）导致任何中断。

我不懂Java，但是我已经用C ++做到了。其他人已经说过，这会使行很长，而且很难阅读，但我已经做过很多次了：

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

这样更好：

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

至少，我认为。但是，如果您愿意，欢迎您对我投反对票，并称我为糟糕的程序员。而且我不知道您是否甚至可以使用Java来做到这一点。

这种称为“流利接口”的方案（双关语意）现在正变得非常流行。可以接受，但实际上不是我的茶。

因为它不会返回void，所以它不再是有效的JavaBean属性设置器。如果您是使用可视化“ Bean Builder”工具的七个人之一，还是使用JSP-bean-setProperty元素的十七个之一，那么这可能很重要。

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

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

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

这根本不是一个坏习惯。但这与JavaBeans Spec不兼容。

并且有很多规范取决于这些标准访问器。

您可以始终使它们彼此共存。

public class Some {
    public String getValue() { // JavaBeans
        return value;
    }
    public void setValue(final String value) { // JavaBeans
        this.value = value;
    }
    public String value() { // simple
        return getValue();
    }
    public Some value(final String value) { // fluent/chaining
        setValue(value);
        return this;
    }
    private String value;
}

现在我们可以一起使用它们。

new Some().value("some").getValue();

这是不可变对象的另一个版本。

public class Some {

    public static class Builder {

        public Some build() { return new Some(value); }

        public Builder value(final String value) {
            this.value = value;
            return this;
        }

        private String value;
    }

    private Some(final String value) {
        super();
        this.value = value;
    }

    public String getValue() { return value; }

    public String value() { return getValue();}

    private final String value;
}

现在我们可以做到这一点。

new Some.Builder().value("value").build().getValue();

如果您在整个应用程序中使用相同的约定，那似乎很好。

另一方面，如果您的应用程序的现有部分使用标准约定，我会坚持使用它，并将构建器添加到更复杂的类中

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

Paulo Abrantes提供了另一种使JavaBean setter变得流畅的方法：为每个JavaBean定义一个内部构建器类。如果您使用的工具会受到返回值的设置器的困扰，那么Paulo的模式可能会有所帮助。

我支持有“ this”回报的二传手。我不在乎它是否不符合Bean要求。对我来说，如果可以使用“ =”表达式/语句，则返回值的设置方法就可以了。

我曾经更喜欢这种方法，但是我决定反对。

原因：

• 可读性。将每个setFoo（）放在单独的行中可使代码更具可读性。与单次编写代码相比，您通常阅读代码的次数要多得多。
• 副作用：setFoo（）应该只设置字段foo，除此之外别无其他设置。返回这是一个额外的“那是什么”。

我看到的Builder模式不使用setFoo（foo）.setBar（bar）约定，而是使用更多foo（foo）.bar（bar）。也许正是出于这些原因。

一如既往地关乎口味。我只是喜欢“最少的惊喜”方法。

这种特定的模式称为方法链接。Wikipedia链接，其中提供了更多解释和使用各种编程语言进行操作的示例。

PS：只是想把它留在这里，因为我一直在寻找具体的名字。

乍一看：“可怕！”。

进一步思考

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

实际上比以下情况更容易出错

Employee anEmployee = new Employee();
anEmployee.setName("xxx");
...
list.add(anEmployee);

非常有趣。在工具包中添加想法...

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

如果我可以添加一些东西，那么这个问题呢：

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

通常，这是一个好习惯，但是您可能需要使用布尔类型的set-type函数来确定操作是否成功完成，这也是一种方法。通常，没有教条可以说这是件好事或卧床不起，这当然取决于情况。

从声明

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

我看到两件事

1）毫无意义的陈述。2）缺乏可读性。

这可能不太可读

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

我已经进行了一段时间的设置，唯一真正的问题是那些使用严格的getPropertyDescriptors来获取bean读/写bean访问器的库。在这些情况下，您的Java“ bean”将不会具有您所期望的扭曲。

例如，我没有确定要进行测试，但是当Jackson从json / maps创建Java对象时，Jackson不会将它们识别为setter不会令我感到惊讶。我希望这是错误的（我会尽快对其进行测试）。

实际上，我正在开发一个以SQL为中心的轻量级ORM，并且必须在getPropertyDescriptors之间添加一些代码，以将其返回给已识别的setter。

很早以前就回答了，但是我的两分钱。我希望这个流利的界面得到更多的使用。

重复'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进行调整，以在某些情况下正确执行此操作，例如继承和工具。

如果可用，最好使用其他语言构造。例如，在Kotlin中，您可以使用with，apply或let。如果使用这种方法，则实际上不需要从设置器返回实例。

这种方法允许您的客户端代码为：

• 不管返回类型
• 易于维护
• 避免编译器副作用

这里有些例子。

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

如果我正在编写API，则会使用“返回此值”来设置只能设置一次的值。如果我还有用户可以更改的任何其他值，则改用标准的void设置器。

但是，这实际上是一个优先事项，我认为链设置器看起来确实很酷。

我同意所有发布者的观点，声称这违反了JavaBeans规范。有理由保留这一点，但我也觉得使用此Builder模式（已暗示）有其应有的地位。只要不是在所有地方都使用它，就应该可以接受。对我来说，“ It's Place”是端点对“ build（）”方法的调用。

当然，还有其他方法可以设置所有这些内容，但是这样做的好处是它避免了1）多参数公共构造函数和2）部分指定的对象。在这里，让构建器收集所需的内容，然后在最后将其称为“ build（）”，这可以确保未构建部分指定的对象，因为该操作的可见性不及公共。替代方案是“参数对象”，但是恕我直言，只是将问题推回了一个层次。

我不喜欢多参数构造函数，因为它们使传递许多相同类型的参数的可能性更大，这可以使将错误的参数传递给参数更容易。我不喜欢使用很多设置器，因为可以在完全配置对象之前使用该对象。此外，使用“ build（）”方法可以更好地满足基于先前选择的默认值的概念。

简而言之，如果使用得当，我认为这是一个好习惯。

坏习惯：二传手设置吸气剂

显式声明一个方法，该方法适用于U

setPropertyFromParams(array $hashParamList) { ... }