Java 在其中链接同一对象的方法结果的设计模式的名称是什么？

我见过这种设计模式，但我记不起它的名字：

class Number {
  private int myNumber;
  public Number(int arg) {this.myNumber = arg;}
  public Number add (int arg) {return new Number(myNumber + arg);}
  public Number subtract (int arg) {return new Number(myNumber - arg);}
}

因此，您使用它的方式是：

Object result = (new Number(1)).add(2).subtract(1).add(3);

关键是，您可以将方法结果链接在一起

---

我的问题是：将同一对象的方法结果链接在一起的设计模式的名称是什么？

我听说过。这使得调试变得更加困难在某些情况下，整个操作链可能被视为一条语句，因此在我看来：这不是一个好主意。

仅调用链中类的方法并不符合模式的要求。设计模式记录在设计级别，这些解决方案独立于实现。有些模式的代码和UML图看起来相似，但由于其意图不同，它们表示不同模式的实现（例如状态和策略）。但在构建器模式中可以看到，为构建对象调用这样一个链时，可能会有许多可选参数的排列组合。其中，原始对象是使用强制参数创建的，并由生成器在其严格控制下根据客户的要求重新配置，而不破坏封装。Joshua Bloch的《高效Java：编程语言指南》在书中演示了这种构建器模式的有效使用

界面流畅？我不同意你的看法。在为回归测试构建复杂的数据配置时，我经常使用这种模式，它很好地保持了代码的整洁。与构建器模式一起使用，它还允许很好地重用。如果你使用得当，我认为这是个好主意。和大多数模式一样，你说的“更难调试”，是指尝试用IDE进行调试吗？我完全同意。当您有5个调用相互链接，并引发异常时。。。享受细节的乐趣。我认为IntelliJ的新版本仅仅为流畅的流表达式添加了一个特殊的调试器并不奇怪。除此之外，根据“流利”的方式，有时可能只是违反了德米特定律。@GhostCat你知道异常断点吗？非常有效！IDE工效学问题永远不应该成为编写错误和不可读代码的原因。不使用这种模式就失去了一个很好的机会。因为你总是和同一个物体交流，至少如果你用我提议的形式，那么你很好地遵守了“得墨忒尔定律”。也许在一个额外的情况下，我们应该看看你心目中的坏例子。在这里，我无法理解你对这种模式的问题。