让setter返回"this“是不好的做法吗？
在java中让setters返回"this“是个好主意还是坏主意？
public Employee setName(String name){
this.name = name;
return this;
}此模式非常有用，因为这样您就可以像这样链接setter：
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);...but，它有点儿违背了标准惯例。我想这可能是值得的，因为它可以让setter做一些其他有用的事情。我曾见过这种模式在某些地方使用(例如JMock、JPA)，但它似乎并不常见，而且通常只用于定义良好的API，在这些API中到处都使用这种模式。
更新：
我所描述的显然是正确的，但我真正寻找的是关于这是否普遍可接受的一些想法，以及是否存在任何陷阱或相关的最佳实践。我知道Builder模式，但它比我所描述的要复杂一些-正如Josh Bloch所描述的那样，有一个用于创建对象的相关静态Builder类。
回答 27
Stack Overflow用户
发布于 2009-08-28 04:36:43
我不认为它有什么特别的问题，这只是一个风格问题。它在以下情况下很有用：
知道您需要一次设置多个字段(包括在construction)
- you
- 您在编写代码时知道您需要设置哪些字段，以及
- 您想要设置哪些字段有许多不同的组合。
此方法的替代方法可能是：
- One mega构造函数(缺点:您可能会传递许多空值或默认值，并且很难知道哪个值对应于few)
- Factory/static重载构造函数(缺点:一旦您有超过一个
- 方法，就会变得很笨拙(缺点:与重载构造函数相同-一旦有更多方法，就会变得笨拙)
如果你只打算一次设置几个属性，我会说这不值得返回'this‘。如果你后来决定返回其他东西，比如状态/成功指示器/消息，它肯定会失败。
Stack Overflow用户
发布于 2009-08-28 04:25:52
这是一个不错的练习。这是一种越来越普遍的做法。大多数语言不需要处理返回的对象，所以它不会改变“正常”的setter使用语法，但允许您将setter链接在一起。
这通常称为构建器模式或fluent interface。
这在Java API中也很常见：
String s = new StringBuilder().append("testing ").append(1)
.append(" 2 ").append(3).toString();Stack Overflow用户
发布于 2009-09-02 03:32:41
总结一下：
- 它被称为“流畅的接口”，或者“方法代码不是”标准的Java，尽管你现在确实看到它越来越多(在jQuery中工作得很好)
- 它违反了JavaBean规范，所以它会破坏各种工具和库，特别是JSP构建器和Spring.
- 它可能会阻止Java虚拟机通常做的一些优化
- 一些人认为它清理代码，其他人认为它“可怕”
<代码>F211
还有几点没有提到：
- 这违反了每个函数应该做一件事(并且只做一件事)的原则。你可能相信，也可能不相信，但在Java语言中，我相信它工作得很好。
- IDE不会为你生成这些代码(默认情况下)。
- I最后，这是一个真实的数据点。我在使用像这样构建的库时遇到了问题。Hibernate的查询构建器就是现有库中的一个例子。因为Query的set*方法是返回查询的，所以仅仅通过查看签名是不可能知道如何使用它的。例如：
Query setWhatever(String What)；
- 它引入了一个歧义:该方法是否修改了当前对象(您的模式)，或者，也许Query真的是不可变的(一个非常流行且有价值的模式)，并且该方法返回一个新的模式。这只会使库更难使用，而且许多程序员不会利用这一特性。如果setter是setter，那么如何使用它就会更清楚。
https://stackoverflow.com/questions/1345001
复制相似问题
腾讯云开发者
