方法链的优缺点以及用对象本身替换所有无效返回参数的可能性 [英] Benefits and drawbacks of method chaining and a possibility to replace all void return parameters by the object itself

问题描述

我最感兴趣的是 Java，但我认为这是一个普遍的问题.最近我一直在使用 Arquillian 框架 (ShrinkWrap)，它使用了很多方法链.方法链的其他示例是StringBuilder、StringBuffer 中的方法.使用这种方法有明显的好处:减少冗长就是其中之一.

I am mostly interested in Java, but I think it's a general question. Recently I've been working with Arquillian framework (ShrinkWrap) that uses a lot of method chaining. Other example of method chaining are methods in StringBuilder, StringBuffer. There are obvious benefits of using this approach: reduced verbosity is one of them.

现在我想知道，为什么不是所有具有 void 返回参数的方法都实现为可链接的?链接肯定有一些明显和客观的缺点.因为如果所有方法都是可链接的，我仍然可以选择不使用它.

Now I was wondering, why aren't all methods which have void return parameter implemented as chainable? There must be some obvious and objective drawback in chaining. Because if all methods are chainable, I can still choose not to use it.

我不是要求更改 Java 中的现有代码，这可能会破坏某处的某些内容，但解释为什么不使用它也会很好.我更多地是从未来框架(用 Java 编写)设计的角度提出问题.

I am not asking to change the existing code in Java, which might break something somewhere, but explanation why wasn't it used would be nice as well. I am more asking from a future framework (written in Java) design perspective.

我发现了一个类似的问题，但最初的提问者实际上想知道为什么它被认为是一个好习惯:方法链 - 为什么它是一种好的做法，或者不是?

I have found a similar question, but the original asker is actually wondering why it IS considered a good practice: Method chaining - why is it a good practice, or not?

虽然有一些可用的答案，但我仍然不确定链接的所有优点和缺点是什么，以及将所有 void 方法链接起来是否有用.

推荐答案

缺点

• 主要是它混淆了签名，如果有东西返回一个新的例如，我不希望它也是一个 mutator 方法.例如如果一个向量有一个 scale 方法然后如果它有回报我会假设它返回一个由输入缩放的新向量，如果没有，那么我希望它能够在内部扩展.
• 当然，如果类被扩展，你会遇到问题，在链接过程中，你的对象被强制转换为超类型.当在父类中声明链接方法，但在子类的实例上使用时，会发生这种情况.

好处

• 它允许将数学方程样式的代码编写为完整的方程，而无需多个中间对象(导致不必要的开销)，例如无需链接向量三叉积的方法(作为一个随机的例子)必须写成

• It allows mathematical equation style code to be written as full equations without the need for multiple intermediate objects (leading to unnecessary overhead), for example without method chaining the vector triple cross product (as a random example) would have to be written either as

MyVector3d tripleCrossProduct=(vector1.multiply(vector2)).multiply(vector3);

它的缺点是创建了一个必须被创建和垃圾回收的中间对象，或者

which has the disadvantage of creating an intermediate object which must be created and garbage collected, or

MyVector3d tripleCrossProduct=vector1;
tripleCrossProduct.multiplyLocal(vec2);
tripleCrossProduct.multiplyLocal(vec3);

避免创建中间对象但非常不清楚，变量名tripleCrossProduct实际上是一个谎言，直到第3行.但是，如果你有方法链接这个可以用正常的数学方式简洁地编写，而不会创建不必要的中间对象.

which avoids the creation of intermediate objects but is deeply unclear, the variable name tripleCrossProduct is in fact a lie until line 3. However, if you have method chaining this can be written concisely in a normal mathematical way without creating unnecessary intermediate objects.

MyVector3d tripleCrossProduct=vector1.multiplyLocal(vector2).multiplyLocal(vector3);

所有这些都假设vector1是牺牲的并且永远不需要再次使用

All of this assumes that vector1 is sacrificial and will never need to be used again

当然还有明显的好处；简洁.即使你的操作在我上面的例子中没有链接，你仍然可以避免对对象的不必要的引用

And of course the obvious benefit; brevity. Even if your operations aren't linked in the manor of my above example you can still avoid unnecessary references to the object

SomeObject someObject=new SomeObject();
someObject
  .someOperation()
  .someOtherOperation();

NB MyVector3d 并未用作真正的 Java 类，但假定在调用 .multiply() 方法时执行叉积..cross() 没有被使用，这样意图"对于那些不熟悉向量演算的人来说更清楚
NB Amit 的解决方案是使用多行方法链接的第一个答案，为了完整性，我将其包含在第四个要点中

NB MyVector3d is not being used as a real class of Java, but is assumed to perform the cross product when .multiply() methods are called. .cross() is not used so that the 'intention' is clearer to those not familiar with vector calculus
NB Amit's solution was the first answer to use multiline method chaining, I include it as part of the forth bullet point for completeness

这篇关于方法链的优缺点以及用对象本身替换所有无效返回参数的可能性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！