我主要对Java感兴趣，但我认为这是一个普遍的问题。最近我一直在使用Arquillian框架(ShrinkWrap)，该框架使用了大量的方法链式调用。StringBuilder、StringBuffer等类中也有方法链式调用的例子。使用此方法的明显优点之一是减少冗余。
现在我想知道，为什么不将所有返回void参数的方法都实现为链式调用呢？肯定存在一些明显而客观的缺点。因为如果所有方法都可链接，我仍然可以选择不使用它。
我不是要求改变Java中现有的代码，在某个地方会出现问题，但从未来Java框架设计的角度考虑，解释为什么没有使用链式调用也很好。
我找到了一个类似的问题，但原问题的提问者实际上正在思考为什么链式调用被认为是一个好的实践: Method chaining - why is it a good practice, or not?
虽然已经有一些答案可供参考，但我仍然不确定链式调用的所有优缺点以及是否将所有无返回值方法都实现为链式调用是否有价值。
缺点
优点
它允许编写以数学方程式为风格的代码作为完整方程式，而无需多个中间对象（导致不必要的开销），例如，如果没有方法链接，则向量三重叉积（作为随机示例）必须写成
MyVector3d tripleCrossProduct=(vector1.multiply(vector2)).multiply(vector3);
有一个缺点，就是会创建一个中间对象，需要被创建和垃圾回收。
MyVector3d tripleCrossProduct=vector1;
tripleCrossProduct.multiplyLocal(vec2);
tripleCrossProduct.multiplyLocal(vec3);
这种方法避免了中间对象的创建，但是却非常不清晰，变量名tripleCrossProduct直到第3行才被真正实现。但是，如果你使用方法链，就可以用一种正常的数学方式简洁地写出来，而不会创建不必要的中间对象。
MyVector3d tripleCrossProduct=vector1.multiplyLocal(vector2).multiplyLocal(vector3);
所有这些都假设vector1是牺牲的，并且永远不需要再次使用
当然，明显的好处是简洁性。即使您的操作没有像我上面的示例那样链接，您仍然可以避免不必要地引用对象
SomeObject someObject=new SomeObject();
someObject
.someOperation()
.someOtherOperation();
请注意，Java中的MyVector3d并非真正的类，但假定在调用.multiply()方法时会执行叉乘操作。没有使用.cross()方法，以使那些不熟悉向量微积分的人更容易理解“意图”
请注意，Amit的解决方案是第一个使用多行方法链接的答案，我将其作为完整性的一部分包含在第四个要点中
方法链是一种实现流畅接口的方式，无论编程语言如何。它的主要优点（可读性代码）告诉您何时使用它。如果没有特别需要可读性的代码，则最好避免使用它，除非API自然设计为返回上下文/对象作为方法调用的结果。
必须将流畅接口与命令查询API进行比较。为了更好地理解它，让我写出命令查询API的项目列表定义。简单来说，这只是标准的面向对象编码方法：
Command。命令不返回值。Query。查询不修改数据。遵循命令查询API将带来以下好处:
但命令查询API存在某些原因，并且确实更易读。那么我们如何同时拥有流畅接口和命令查询API的好处呢？
答案：必须在命令查询API之上实现流畅接口（而不是通过使用流畅接口替换命令查询API）。将流畅接口视为命令查询API的外观即可。毕竟，它被称为流畅“接口” - 标准（命令查询）API的可读性或方便性接口。
通常，在命令查询API准备好之后（编写，可能进行单元测试，精细调试），您可以在其上编写一个流畅接口软件层。换句话说，流畅接口通过利用命令查询API来实现其功能。然后，在需要方便和可读性的任何地方使用流畅接口（通过方法链接）。但是，一旦您想了解到底发生了什么（例如调试异常），您可以随时深入研究命令查询API-良好的面向对象代码。
NullPointerException或其他Exception时很难。假设你有以下代码：
String test = "TestMethodChain";
test.substring(0,10).charAt(11); //这只是一个例子
当执行上面的代码时，您将得到“String index out of range”异常。在实时情况下遇到这种情况时，可以知道哪一行出错了，但不知道是链接方法的哪一部分引起了错误。因此，需要明智地使用它，其中已知数据始终会出现或错误已经正确处理。您可能想阅读Martin Fowler的流畅接口(Fluent Interface)
总结
这种模式在需要对同一对象进行一系列更新操作，并且更新操作不需要返回任何更新状态时非常有用。例如，我在为数据库层编写的一些API中使用了这种模式。为了根据许多条件获取一些行，需要将许多条件添加到WHERE子句中。使用这种模式，可以按如下方式添加条件。
CriteriaCollection().instance()
.addSelect(Criteria.equalTo(XyzCriteria.COLUMN_1, value1))
.addSelect(Criteria.equalTo(XyzCriteria.COLUMN_2, value2))
.addSelect(Criteria.isIn(XyzCriteria.COLUMN_3, values3))
.addOrder(OrderCriteria.desc(XyzCriteria.Order.COLUMN_1));
它最终提高了代码的可读性。
如果您喜欢 不可变性 和 函数式编程，您永远不会返回 void。
没有返回值的函数仅用于其 副作用。
当然，有时这种情况并不适用，但是返回 void 的函数可以被视为尝试以不同方式解决问题的提示。
copyTo(T other) 方法的情况。通常你不希望它返回任何东西，但如果它返回一个相同类型的对象，你会期望哪个对象呢？这种问题可以通过文档来澄清，但方法签名仍然存在歧义。public class MyObject {
// ... my data
public MyObject copyTo(MyObject other) {
//... copy data
// what should I return?
return this;
}
}
对象具有属性和方法。每个方法都实现了对象的整体目的的一部分。某些类型的方法，如构造函数和获取器和设置器，执行属性和对象本身的生命周期管理。其他方法返回对象及其属性的状态。这些方法通常是非空的。
空方法有两种类型： 1. 关于对象或属性的生命周期管理。 2. 具有在方法内完全处理的输出，并且不应在任何其他地方引起任何状态更改。
广告1.它们属于对象的内部工作。 广告2.参数的信息用于在方法内执行一些工作。方法完成后，对象本身或其中一个参数的内部状态都没有发生变化。
但是为什么要使方法返回void，而不是例如布尔值（成功或失败）？方法返回void（如setter中）的动机是该方法旨在没有副作用。返回true或false可能是副作用。当按设计执行方法时，void意味着该方法没有副作用。返回异常的void方法很好，因为异常不是方法正常处理的副作用。
返回void的方法意味着它本质上是一个孤立的工作方法。一系列void方法是一系列松散耦合的方法，因为没有其他方法可以依赖其前任的结果，因为没有任何方法有任何结果。对此有一个设计模式，即责任链设计模式。链接不同的记录器是一个传统的例子，以及在servlet api中调用后续过滤器。
以有意义的方式链接void方法意味着这些方法所工作的共享对象在每个步骤之后处于可理解的状态，该状态由工作于该对象的void方法确定。所有后续调用都不能依赖其前任的结果，也不能影响其自身调用后的调用工作。您可以确保最简单的方法是不让它们更改对象的内部状态（例如记录器示例），或者让每个方法更改对象内部状态的另一部分。
在我看来，可以链接的无返回值方法只有那些具有第二种特性并共享某种类型处理的方法。对于涉及类生命周期的无返回值方法，我不会将它们链接起来，因为每个方法都是对象整体状态的不同部分的更改。这些方法的存在可能随着类设计的任何更改而发生变化，因此我不建议将这些方法链接起来。此外，由第一种类型的无返回值方法抛出的所有异常彼此独立，而您可能期望由共享某种类型处理的第二种风格的链接无返回值方法抛出的异常具有某些共同点。