Java 代码中业务代码的方法入参是 Function 这种？真的合适吗？

[lvxiaomao]

众所周知，java 提供了 Function 、Supplier 等函数式接口。

在新公司的业务代码中，入参是 Function 这种，我看了一下是因为有 2 个地方调用，这种直接调用一个封装好的方法不行吗？ 否则每次看到在方法内调用这 func.get()的时候，还得返回代码入参看看具体的 function 是啥，真的好麻烦呀；

如果是提供工具类，使用函数式参数我认为是合理的，但是业务代码真的适合这样写吗？

你们的代码中有这样的入参吗？

[jorneyr]

Java 不支持函数式编程。

[wetalk]

换个思路，把函数式接口当成匿名内部类的对象，就容易接受了

[unco020511]

这种很正常吧,反正我们从 java 换到 kotlin 后,很多函数式参数

[lvxiaomao]

@wetalk #2 但是读起来真的麻烦，读到方法一半，然后返回去看看这个 function 是啥

[lvxiaomao]

@unco020511 #3 就是读起来费劲

[mgzu]

有没有可能是参数名命名的问题呢，func 修改为更具体的命名，如：getXXX ，doXXX ，达到见名知意的效果

[Oktfolio]

用啊，为什么不用？

[TWorldIsNButThis]

再正常不过了

[TWorldIsNButThis]

另外多说一嘴，函数入参是最简单的 ioc 方式

[adoal]

不如再换个公司，还在用 JDK 1.6 维护遗留系统的

[xiaoHuaJia]

用 贼好用

[issakchill]

挺好用的啊

[hepin1989]

挺好的，合适，不过可以看看团队的程度。

[luzemin]

挺好用的，对标 C#中的委托，把函数当参数传递

[jiangteng]

都提供了为什么不用，确实能写起来更方便啊，特别是针对逻辑半截需要做不同处理的

[chendy]

有没有一种可能这玩意叫 策略模式
看着费劲可能是：
1. 抽象不对导致必须关注实现细节
2. 修改维护需要必须看实现细节
反正也就一个 find usage 的事，相比之下还是 一堆 XXService 接口对一个 XXServiceImpl 的 写法最蛋疼…

[gogo789]

在业务代码里面有，感觉确实不太合适，业务代码的特点就是通用性比较差。举例来说，一个 Service 的入参，根据不同的 Function 执行不同的逻辑，以后维护、测试也是个问题，建议还是拆分成两个不同的方法。

[Rache1]

@lvxiaomao #4 Intellij 系列的 IDE ，你可以选中方法后按下 Ctrl+SHIF+I(大写字母 i)，可以有一个小窗来显示这个方法的实现。

[tedzhou1221]

正在学习函数式编程，按理解是函数式编程 易于理解、对测试友好。

[tedzhou1221]

看了 dubbo 源码，服务注册功能。不少地方都用了函数编程。