曾经用过一点的函数式编程

初识函数式编程

刚来公司，打开项目，看到这种写法觉得比较新奇

 

因为我们一般定义一个方法，参数要么是简单参数，要么是对象，第一次看到是一个Function，就这样初识了函数式编程。

点进去Function，是java.util.function下的类

官方解释是Represents a function that accepts one argument and produces a result，表示接受一个参数并生成结果的函数。

后来还看到这种写法，觉得既新奇又有点表示不解

 传入一个Supplier

也是java.util.function下的类，官方解释是表示结果的供应商。

后面逐渐发现在某些人的代码中，这种写法比较多见。经询问，这是我们架构同事比较常用的写法。

还有BiFunction，和Function差不多，调用apply

BiConsumer，官方解释是表示接受两个输入参数而不返回结果的操作。初步理解是通过调用accept来设置或接收参数的操作。用得最少，不是太懂。感兴趣的朋友可以网上查一下。

以上两个也是java.util.function下的类 

自己的运用情况：

我自己不太用这种写法，主要是之前没用过，不太习惯，不太会想到这种用法，就算用也是一些大家比较常见的用法。

思考和回顾：

1.函数式编程有什么特点

函数式编程是java 1.8以后的特性。函数式编程模型，需要定义提供方，再是调用方，可能有点类似生产者-消费者模式。个人理解的话，函数式编程可能比较灵活一些，有点面向过程编程思想的感觉，也不知道理解的对不对。我发现在项目中用函数式编程的场景也不太固定，或许也是方便吧。

2.Function和Supplier有什么区别

个人理解的话，因为用得不多，机制和源码也没怎么了解，从代码上看Supplier可以调用Get方法获取结果，而Function可以调用apply获取结果，感觉Supplier是更多上一层的

可以通过lamda表达式声明Supplier，lamda右边是也是一个方法。

声明Function就相对简单简单一些，任何一个外部的，在接口中的方法可以是Function的。

3.函数式编程有什么应用场景

应用场景的话，个人感觉可能在定义一些通用的行为规范上可能用得比较多一点，像这边大部分是一些通用的类，比如BaseController，基础组件或工具类，比如公共异常util等。

两年过去了，感觉自己还是不太习惯用吧。

其实每一家公司都有自己的一些编程风格，这种编程风格一般是由公司的总监、架构师或开发负责人决定的，就像《亮剑》中说的，一个组织的风气一般是有组织的头头决定的，这种风格有一定的代表性，就像上一份公司常见的函数式编程，也有一定的局限性，是说可能换一家公司可能就不喜欢用函数式编程了。

真正是自己的，是要理解它的用法，而不是只直到这么个东西。

以上如果有哪里写得不对的地方，欢迎指正。