在我工作的公司,有一份文档描述了我们应该在Java中遵循的良好实践.其中之一是避免返回的方法,this例如:
class Properties {
public Properties add(String k, String v) {
//store (k,v) somewhere
return this;
}
}
Run Code Online (Sandbox Code Playgroud)
我会有这样一堂课,所以我能写:
properties.add("name", "john").add("role","swd"). ...
Run Code Online (Sandbox Code Playgroud)
我已经多次见过这样的习语,就像在里面一样,StringBuilder并没有发现任何问题.
他们的论证是:
...可能是同步问题的根源或对目标对象状态的失败预期.
我想不出这可能是真的情况,你们有谁能举个例子吗?
编辑该文档没有指定任何有关可变性的内容,因此我没有看到链接调用和执行以下操作之间的差异:
properties.add("name", "john");
properties.add("role", "swd");
Run Code Online (Sandbox Code Playgroud)
我会尝试与发起人联系,但我想用我的枪加载,这就是为什么我发布了这个问题.
解决:我得与其中一位作者交谈,他的初衷显然是为了避免释放尚未准备好的对象,比如在Builder模式中,并解释说如果在调用之间发生上下文切换,则对象可能在无效的状态.我认为这与返回无关,this因为你可以犯同样的错误购买逐个调用方法,并且更多地与正确地同步构建过程有关.他承认该文件可能更加明确,并将很快修改.胜利是我的/我们的!
我的猜测是他们反对可变状态(通常是正确的).如果您没有设计返回的流体接口this,而是返回具有已更改状态的对象的新不可变实例,则可以避免同步问题或者没有"failed expectations about the states of target objects".这可能解释了他们的要求.
这种做法唯一严肃的基础是避免可变对象; 批评它"混乱"并导致"失败的期望"是相当薄弱的.在不首先熟悉其语义的情况下,永远不应该使用对象,并且为了满足那些选择不读Javadoc的人而强制执行API的约束根本不是一个好习惯 - 特别是因为,正如您所注意到的,返回this实现流畅的API设计是Java中的标准方法之一,实际上是一个非常受欢迎的方法.
| 归档时间: |
|
| 查看次数: |
358 次 |
| 最近记录: |