我喜欢以函数式风格进行编程。但我突然想到,将函数作为参数传递有时可能会在组件之间产生比使用非函数参数传递更强的耦合。
例如,在下面的(人为的)示例中:A、B 和 C 通过 C 的函数参数的输出类型、C 的 int 参数的类型以及 C 的函数的元数和输入类型进行耦合争论。如果 A 想要将其函数更改为 BiFunction,B 和 C 都必须更改。
public class Functional {
public void A() {
C(i -> String.valueOf(i + 2), 123);
}
public void B() {
C(i -> String.valueOf(i + 1), 123);
}
private String C(Function<Integer, String> f, int a) {
int len = String.valueOf(a).length();
return f.apply(len);
}
}
将此与 A 和 B 预先计算函数结果,然后将 String 结果和第二个 int 参数传递给 C 的示例进行对比。这里 A、B 和 C 仅在两个位置耦合 - 两个C 的参数。计算第一个参数的函数可以自由更改。
显然,传递函数有其一席之地,但当事情变得更加复杂时,这种问题似乎会变得更加复杂并创建僵化的代码。我很想听听您用来决定何时以这种方式耦合可以或不可以的任何经验法则。
最佳答案
在您的示例中,我建议遵循 Single Responsibility 的原则
Gather together the things that change for the same reasons. Separate those things that change for different reasons.
因此,选择以何种方式将 A、B 与 C 结合取决于它们要改变的原因。
<小时/>从你的例子中想到的另一个原则是 Rule of least power
Given a choice of solutions, pick the least powerful solution capable of solving your problem
在简化的示例函数中,C
不需要函数作为参数。该函数可以在 A
、B
端调用。
关于java - 函数作为参数 : Strong Coupling?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38664878/