采用和返回相同类型的方法的管道答案

【问题标题】：Pipeline of methods taking and returning the same type采用和返回相同类型的方法的管道
【发布时间】：2017-09-16 11:54:46
【问题描述】：

在数据清理应用程序中，我有一系列方法，每个方法都接受一个自定义对象并在经过一些处理后返回它。

我知道将这些方法中的每一个放在自己的类中并将它们链接在一起的设计模式，但我对拆分这个类不感兴趣。它是嵌入在一个相当大的 Java 单体中的一个类中间的几行代码。出于同样的原因，我不会为这小段代码包含来自 Scala 或其他一些函数式语言的单个模块。

这些方法必须以正确的顺序执行，因为每个方法的逻辑取决于已经完成的操作。因此我给了他们新的编号名称，我希望保留这个编号的顺序。

我现在的代码是这样的：

customObject = method1(customObject);
customObject = method2(customObject);
customObject = method3(customObject);
customObject = method4(customObject);
customObject = method5(customObject);
customObject = method6(customObject);

有没有更流畅的方式将它们链接在一起，不颠倒它们在代码中出现的顺序？换句话说，我认为以下内容可能具有误导性（真实的方法名称不会显示它们是向后列出的）：

customObject = method6(method5(method4(method3(method2(method1(customObject))))));

和

customObject = method6(customObject)
 = method5(customObject)
 = method4(customObject)
 = method3(customObject)
 = method2(customObject)
 = method1(customObject);

（无论如何，除了在读取时颠倒顺序，后者不是有效的Java代码，因为如果右侧有方法调用，编译器需要左侧有一个变量）

这是一个关于一小段代码的小问题。我怀疑答案是否定的，因为每行中的处理方式从右到左流动（进入方法参数，并分配给左侧的变量名）。但是我无法摆脱这种烦人的感觉，我可能会在语言中遗漏一些东西，这将允许更优雅地链接这些方法调用。或许这是 Java 做不到的。

【问题讨论】：

为什么不创建一个 customObject 子类，以便将它们与 customObject 链接起来？
@Dave Newton：从问题中并不清楚，但是 customObject 是 List 的一个实例（我故意省略了这个，因为它在处理过程中不能流式传输或以其他方式分解，并且我想避免这样的答案）。我认为仅仅为仅在这几行中使用的数据结构创建另一个类是不值得的。

标签： java chaining

【解决方案1】：

您可以使用fluent interface 模式。像这样的：

dataCleaner
    .method1(customObject)
    .method2(customObject)
    .method3(customObject)
    .method4(customObject)
    .method5(customObject)
    .method6(customObject)

dataCleaner 上的每个方法都返回 this，例如

public DataCleaner method1(CustomObject customObject) {
    // do some cleaning ...
    // ...
    return this;
}

注意事项：

这假设每个方法都会以这样一种方式改变customObject，使其准备好成为下一个方法的输入。根据您显示当前代码的方式，我认为这个假设是有效的。如果这无效，那么您可以使 DataCleaner 有状态并通过类成员在离散方法之间共享状态，可能是这样的：
```
CustomObject clean = new DataCleaner(customObject)
    .method1()
    .method2()
    .method3()
    .method3()
    .method5()
    .method6()
    .get();
```
可以说上述方法只是方法链接而不是正式的流畅接口，但您的实际实现可能会返回一些东西，或者可能有一些方法需要额外的上下文等所有这些都会带来它更接近流畅接口的规范形式。抛开如何描述这种模式的语义不谈，它至少可以让你整理你的代码，并以一种易于理解的方式表达这个方法链之间的依赖关系。

【讨论】：