StreamAPI源码分析之三（Collectors工厂类方法基础打底篇）

前言

上一小节总结了Collectors工厂类内部除方法之外的设计，这一小节接着Collectors工厂类继续分析，对于Collectors工厂类的静态方法进行深入分析。但是如果直接进入静态方法分析，会出现大家不知道它的那些参数是谁传入的，反正有些静态方法是没有传入参数的，但是方法里面的实现是有参数传递的，这个可能理解起来不再像是原来的，你看到的方法有传参，实现效果已经知道的情况了，而是函数式方法写的方法不知道，但是用的时候会明确是什么类型，传入参数确定。
接下来就先基础打底，把目前JDK的函数式接口进行简单分析，太细节的这里就不作分析了，后面如果有人希望看到更细致的这些内部函数式接口的总结，可以给我留言，我会在后面考虑安排更细致的。ok,现在就先开始我们的基础打底吧。

前传

首先需要大家普及一下基础的函数式接口，不然没法理解静态函数式方法，一些参数不知所以，为啥没有传入参数，在方法实现里面就会有参数的流通，中间确实是有参数传入的，但是并不是函数自己本身，而是使用的时候类型推断传入的。
而这些新的函数式接口在java.util.function包下。

一、Function<T, R>

@FunctionalInterface
public interface Function<T, R> {

    /**
     * 将此函数应用于给定参数。
     *
     * @param t 函数参数
     * @return R  函数结果
     */
    R apply(T t);
}

这里函数的其他静态方法就不做分析了，直接分析最基础的，这个函数表示接受一个参数并生成结果的函数。这是一个功能接口，其功能方法是apply（Object）；

二、Supplier

@FunctionalInterface
public interface Supplier<T> {

    /**
     * 获取一个结果
     *
     * @return T 结果
     */
    T get();
}

表示结果的提供者。不要求每次调用供应商时都返回新的或不同的结果。这是一个函数接口，其函数方法是get（）;

三、Consumer

@FunctionalInterface
public interface Consumer<T> {

    /**
     * 对给定参数执行此操作。
     *
     * @param t 输入参数
     */
    void accept(T t);
}

表示接受单个输入参数并没有返回结果的操作。与大多数其他功能接口不同，Consumer预期通过副作用运行。这是一个功能接口，其功能方法是accept（Object）

四、Predicate

@FunctionalInterface
public interface Predicate<T> {

    /**
     *	对给定参数计算此谓词，换一种解释就是判断条件是否成立，如“1”.equals（“2”）是true或者false
     *
     * @param t 输入参数
     * @return   如果条件匹配成功返回true,否则false
     */
    boolean test(T t);
}

表示一个参数的谓词（布尔值函数）。这是一个功能接口，其功能方法是test（Object）。

基础四大函数式接口实战

private void excIfInfo(String option, Predicate<String> fs, Consumer<String> f,String info){
        if (fs.test(option)){
            f.accept(info);
        }
    }
//调用函数式封装的方法
puibic String zzz(){

Consumer<String> f=f::setFinancialRelatedRisks;
Predicate<String> fs=(s)->!FIRST_JUDGE_SUCCESS.equals(s);

	excIfInfo(f.getFinancialRelatedRisks(),fs,f,type);
}
//调用函数式封装的方法
puibic String www(String codeDetail){

Consumer<String> f=(s)->{
		String s=“123”；
		f.setCode(s);
        f.setCodeTwo(codeDetail);	
	};
Predicate<String> fs=(s)->!FIRST_JUDGE_FAIL.equals(s);

	excIfInfo(f.getFinancialRelatedRisks(),fs,f,type);
}

首先， zzz()方法和www()方法判断条件不一样，if代码块中的执行代码也不一样，但是都可以复用这个函数式封装的方法，而且兼容一切单条件判断，处理逻辑是无返回值的代码块。代码复用率大大提升，原来的固定代码块，变成了现在的动态调用时实现的方式。
而这只是最基础的四种函数式接口，接下来讲解他们每个接口的拓展函数式接口。

五、Function<T, R>拓展的函数式接口

• BiFunction<T, U, R>

@FunctionalInterface
public interface BiFunction<T, U, R> {

    /**
     * 将此函数应用于给定参数。
     *
     * @param t 第一个输入参数
     * @param u 第二个输入参数
     * @return 函数返回值
     */
    R apply(T t, U u);
    }

这个函数只是参入参数方便对Function进行了增强

• BinaryOperator

@FunctionalInterface
public interface BinaryOperator<T> extends BiFunction<T,T,T> {
}

对BiFunction的三个参数进行一致性规范，两个输入参数，一个返回参数，都为同一类型参数；

• DoubleFunction

@FunctionalInterface
public interface DoubleFunction<R> {

    /**
     * 将此函数应用于给定参数。
     *
     * @param value 函数参数
     * @return 函数返回
     */
    R apply(double value);
}

Double为前缀的Function，一定是参数直接转换成了double基本类型，函数式接口对大数量下的基本类型和装箱类型进行了优化，避免在从数据库刚拿出来之后就进行比遍历而产生的性能开销，泛型只能是包装类型；至于 LongFunction、IntFunction就不多做描述了。

• ToDoubleFunction

@FunctionalInterface
public interface ToDoubleFunction<T> {

    /**
     * 将此函数应用于给定参数。
     *
     * @param value 函数参数
     * @return 函数返回t
     */
    double applyAsDouble(T value);
}

这个与DoubleFunction不同之处在于前者是参数的时候进行了拆箱，后者是在处理完成的时候进行了拆箱，具体需要哪种接口，还需要视情况而定，

• DoubleBinaryOperator

@FunctionalInterface
public interface DoubleBinaryOperator {
    /**
     * 将此运算符应用于给定的操作数。
     *
     * @param left the first operand
     * @param right the second operand
     * @return the operator result
     */
    double applyAsDouble(double left, double right);
}

DoubleBinaryOperator 函数（它是BinaryOperator的拓展，而BinaryOperator又是BiFunction的拓展）与ToDoubleFunction、DoubleFunction又有一定区别，这个完全的参数、返回值都进行了拆箱；
其他的有关Function的就不说哦了。Supplier、Predicate、Consumer，基本上分析思路和以上差不多，想了解的可以去java.util.function看一下。

六、分析函数式思维

上面我们认识了这些接口，但是很多人肯定还是不知所云，怎么理解呀，就和车已经马上了，怎么开呀，那么接下来我来给大家讲解一下函数式的理解思路，这个至关重要，我当初就是没有弄清楚这一点而不能真正的进入这个思维世界，而目前的情况好多框架都在慢慢函数化，除了那些式函数式的编程语言。当你学会这种思考方式，对于学习其他函数式都具有重要作用。
还是以上面的代码例子进行讲解

private void excIfInfo(String option, Predicate<String> fs, Consumer<String> f,String info){
        if (fs.test(option)){
            f.accept(info);
        }
    }
//调用函数式封装的方法
puibic String zzz(){
	//消费者
	Consumer<String> f=f::setFinancialRelatedRisks;
	//断言
	Predicate<String> fs=(s)->!FIRST_JUDGE_SUCCESS.equals(s);
	//
	excIfInfo(f.getFinancialRelatedRisks(),fs,f,type);
}

在这里做分析

• 我们传统的代码是在方法中写好，就以代码里的if条件一定要写好(也就是要写死，不然不能通过编译)，if中的代码块要写好（也就是要写死），而且只能编写一种逻辑，很死板。调用方不需要做详细实现，任务放给了封装方法的一方，如图所示
  
• 函数式将打破这样的固定式职责，而这个时候封装方法的复用性将大大提升，调用方需要做详细实现，封装方只需要做好骨架即可。
  如图所示：
  
• 触发逻辑全部在封装方法中，业务逻辑只是实现了，放了进去，并没有直接调用，fs.test(option)对Predicate fs判断条件进行真正调用，f.accept(info)对Consumer f实现的逻辑代码进行了真正调用，业务层只需要写好实现，放进来即可。

总结

本小节只是对Collectors工厂类方法基础打底，对于基础的函数式接口有哪些，如何理解函数式思维进行分析，下一小节，将进行Collectors工厂类方法深入刨析，可能在基础打底的情况下，还是有难理解的部分，希望对函数式感兴趣的可以多看几遍，慢慢就能理解了，功夫下到位，问题不大。。。。