Bruce Eckel - 详解函数式编程（卷二）

Bruce Eckel

读完需要

20

分钟

速读仅需 1 分钟

布鲁斯 • 埃克尔（Bruce Eckel），C++ 标准委员会的创始成员之一，知名技术顾问，专注于编程语言和软件系统设计方面的研究，常活跃于世界各大顶级技术研讨会。
他自 1986 年以来，累计出版 Thinking in C++、Thinking in Java、On Java 等十余部经典计算机著作，曾多次荣获 Jolt 最佳图书奖（被誉为“软件业界的奥斯卡”），其代表作 Thinking in Java 被译为中文、日文、俄文、意大利文、波兰文、韩文等十几种语言，在世界范围内产生了广泛影响。

接上一篇Bruce Eckel - 详解函数式编程（卷一）

5

   

高阶函数

“高阶函数”这名字听起来很吓人，不过看一下定义：

高阶函数只是一个能接受函数作为参数或能把函数当返回值的函数。

先来看看把函数当作返回值的情况：

// functional/ProduceFunction.java
import java.util.function.*;

interface
FuncSS extends Function<String, String> {}   // [1]

public class ProduceFunction {
  static FuncSS produce() {
    return s -> s.toLowerCase();             // [2]
  }
  public static void main(String[] args) {
    FuncSS f = produce();
    System.out.println(f.apply("YELLING"));
  }
}
/* 输出：
yelling
*/

这里 produce()就是高阶函数。

[1] 使用继承，可以轻松地为专门的接口创建一个别名。

[2] 有了 lambda 表达式，在方法中创建并返回一个函数简直不费吹灰之力。要接受并使用函数，方法必须在其参数列表中正确地描述函数类型：

/// functional/ConsumeFunction.java
import java.util.function.*;

class One {}
class Two {}

public class ConsumeFunction {
  static Two consume(Function<One,Two> onetwo) {
    return onetwo.apply(new One());
  }
  public static void main(String[] args) {
    Two two = consume(one -> new Two());
  }
}

当我们要根据所接受的函数生成一个新函数时，就特别有意思了：

// functional/TransformFunction.java
import java.util.function.*;

class I {
  @Override public String toString() { return "I"; }
}

class O {
  @Override public String toString() { return "O"; }
}

public class TransformFunction {
  static Function<I,O> transform(Function<I,O> in) {
    return in.andThen(o -> {
      System.out.println(o);
      return o;
    });
  }
  public static void main(String[] args) {
    Function<I,O> f2 = transform(i -> {
      System.out.println(i);
      return new O();
    });
    O o = f2.apply(new I());
  }
}
/* 输出：
I
O
*/

这里，transform()会生成一个与所传入函数签名相同的函数，不过我们可以生成自己喜欢的任何函数。

这里使用了 Function 接口中的一个叫作 andThen()的默认（default）方法，该方法是专门为操作函数而设计的。顾名思义，andThen()会在 in 函数调用之后调用（还有一个 compose()方法，它会在 in 函数之前应用新函数）。要附加上一个 andThen()函数，只需要将该函数作为参数传递。从 transform()传出的是一个新函数，它将 in 的动作和 andThen()参数的动作结合了起来。

6

   

闭包

在上一节的 ProduceFunction.java 示例中，我们从方法返回了一个 lambda 表达式。这个示例把事情简化了，但是围绕着返回 lambda，还有些问题我们必须研究。这些问题可以用术语闭包（closure）来概括。闭包非常重要，因为它们使生成函数变简单了。

考虑一个更复杂的 lambda 表达式，它使用了其函数作用域之外的变量。当返回该函数时，会发生什么呢？也就是说，当我们调用这个函数时，它所引用的“外部”变量会变成什么呢？如果语言不能自动解决这个问题，那就是很大的挑战了。如果语言能解决这个问题，我们就说这门语言是支持闭包的。我们也可以称其支持词法作用域（lexically scoped），这里还涉及一个叫作变量捕获（variable capture）的术语。Java 8 提供了虽然有限但还算可以的闭包支持，我们将通过一些简单的示例来研究。首先来看一个会返回函数的方法，而该函数会访问一个对象字段和一个方法参数：

// functional/Closure1.java
import java.util.function.*;

public class Closure1 {
  int i;
  IntSupplier makeFun(int x) {
    return () -> x + i++;
  }
}

进一步考虑，这样使用 i 并不是很大的挑战，因为在我们调用 makeFun()之后，这个对象很可能还存在。确实，对于有现存函数以这种方式绑定的对象，垃圾收集器几乎肯定会保留着它。当然，如果我们对同一个对象调用多次 makeFun()，最终就会有多个函数全部共享同样的 i 的存储空间：

// functional/SharedStorage.java
import java.util.function.*;

public class SharedStorage {
  public static void main(String[] args) {
    Closure1 c1 = new Closure1();
    IntSupplier f1 = c1.makeFun(0);
    IntSupplier f2 = c1.makeFun(0);
    IntSupplier f3 = c1.makeFun(0);
    System.out.println(f1.getAsInt());
    System.out.println(f2.getAsInt());
    System.out.println(f3.getAsInt());
  }
}
/* 输出：
0
1
2
*/

每次调用getAsInt()都会让i增加，这表明存储空间是共享的。

如果i是makeFun()中的局部变量，又会怎么样呢？正常情况下，makeFun()执行完毕，i也就消失了。然而这时仍然可以编译：

// functional/Closure2.java
import java.util.function.*;

public class Closure2 {
  IntSupplier makeFun(int x) {
    int i = 0;
    return () -> x + i;
  }
}

makeFun()返回的IntSupplier是在i和x之上构建的闭包，所以当我们调用所返回的函数时，这两个变量都是有效的。然而请注意，这里没有像Closure1.java中那样增加i。尝试增加它，会出现编译错误：

// functional/Closure3.java
// {WillNotCompile}
import java.util.function.*;

public class Closure3 {
  IntSupplier makeFun(int x) {
    int i = 0;
    // x++或i++都不可以：
    return () -> x++ + i++;
  }
}

编译器会对x和i重复报同一个错误：

local variables referenced from a lambda expression must be final or effectively final

显然，如果我们把x和i标记为最终变量，就行得通了，因为无论哪个我们都无法增加了：

// functional/Closure4.java
import java.util.function.*;

public class Closure4 {
  IntSupplier makeFun(final int x) {
    final int i = 0;
    return () -> x + i;
  }
}

但是在x和i不是最终变量时，为什么Closure2.java就可以工作呢？“实际上的最终变量”（effectively final），其意义就出现在这里了。这个术语是为Java 8创建的，它的意思是，虽然我们没有显式地将一个变量声明为最终变量，但是仍然可以用最终变量的方式来对待它，只要不修改它即可。如果一个局部变量的初始值从不改变，它就是“实际上的最终变量”。

如果x和i在所返回的函数中没有被修改，但是在方法中的其他地方被修改了，编译器仍然会将其当作错误。每个自增操作都会产生一条错误消息：

// functional/Closure5.java
// {WillNotCompile}
import java.util.function.*;

public class Closure5 {
  IntSupplier makeFun(int x) {
    int i = 0;
    i++;
    x++;
    return () -> x + i;
  }
}

所谓“实际上的最终变量”，意味着我们可以在变量声明前面加上final关键字，而不用修改其余代码。它实际上就是final的，我们只是懒得说而已。

实际上我们可以这样修复Closure5.java中的问题：在闭包中使用x和i之前，先将其赋值给最终变量。

// functional/Closure6.java
import java.util.function.*;

public class Closure6 {
  IntSupplier makeFun(int x) {
    int i = 0;
    i++;
    x++;
    final int iFinal = i;
    final int xFinal = x;
    return () -> xFinal + iFinal;
  }
}

因为在赋值之后我们并不会修改iFinal和xFinal，所以这里使用final是多余的。

如果使用的是引用呢？我们把int改为Integer：

// functional/Closure7.java
// {无法通过编译}
import java.util.function.*;

public class Closure7 {
  IntSupplier makeFun(int x) {
    Integer i = 0;
    i = i + 1;
    return () -> x + i;
  }
}

编译器还是很聪明的，能看到i被修改了。因为包装器类型可能会被特殊对待，所以让我们用List试一下：

// functional/Closure8.java
import java.util.*;
import java.util.function.*;

public class Closure8 {
  Supplier<List<Integer>> makeFun() {
    final List<Integer> ai = new ArrayList<>();
    ai.add(1);
    return () -> ai;
  }
  public static void main(String[] args) {
    Closure8 c7 = new Closure8();
    List<Integer>
      l1 = c7.makeFun().get(),
      l2 = c7.makeFun().get();
    System.out.println(l1);
    System.out.println(l2);
    l1.add(42);
    l2.add(96);
    System.out.println(l1);
    System.out.println(l2);
  }
}
/* 输出：
[1]
[1]
[1, 42]
[1, 96]
*/

这次成功了：我们修改了List的内容而没有产生编译错误。看这个示例的输出，确实看起来很安全，因为每次调用makeFun()时，都会创建并返回一个全新的ArrayList——这意味着它没有被共享，所以每个生成的闭包都有自己独立的ArrayList，不会互相干扰。

注意，这里将ai声明为最终变量了，不过对这个示例而言，把final拿掉，结果也是一样的（试试吧！）。final关键字应用于对象引用，只是说这个对象引用不能被重新赋值，并不是说我们不能修改对象本身。

看一下Closure7.java和Closure8.java之间的区别，我们可以发现，Closure7.java实际上对i进行了重新赋值。这可能就是引发“实际上的最终变量”错误消息的元凶：

// functional/Closure9.java
// 无法通过编译
import java.util.*;
import java.util.function.*;

public class Closure9 {
  Supplier<List<Integer>> makeFun() {
    List<Integer> ai = new ArrayList<>();
    ai = new ArrayList<>(); // Reassignment
    return () -> ai;
  }
}

重新赋值确实引发了那条编译错误消息。如果我们只修改所指向的对象，Java会接受。只要没有其他人得到对该对象的引用，这可能是安全的。否则就意味着有不止一个实体可以修改该对象，情况会变得非常混乱。[1]

然而，如果现在回头看Closure1.java，还有一个未解之谜。i的修改并没有引发编译错误。而它既不是最终变量，也不是“实际上的最终变量”。这是因为i是外围类的成员，这样做当然是安全的（除了这一事实：我们正在创建会共享可变内存的多个函数）。确实，你可以争辩说这种情况下并没有发生变量捕获。而且可以确定的是，Closure3.java的报错信息特别提到了局部变量。因此，这个规则并不是像说“任何在lambda表达式之外定义的变量都必须是最终变量或实际上的最终变量”那么简单。相反，我们必须从被捕获的变量是“实际上的最终变量”这个角度来考虑。如果它是某个对象中的一个字段，那么它会有独立的生命周期，并不需要任何特殊的捕获，以便在之后这个lambda表达式被调用时，变量仍然存在。

---

[1] 在进阶卷第5章，这一点有更大的意义。那时你会明白，修改共享变量不是线程安全的。

内部类作为闭包

可以用一个匿名内部类来重复我们的示例：

// functional/AnonymousClosure.java
import java.util.function.*;

public class AnonymousClosure {
  IntSupplier makeFun(int x) {
    int i = 0;
    // 同样的规则适用于：
    // i++; // 并非“实际上的最终变量”
    // x++; // 同上
    return new IntSupplier() {
      public int getAsInt() { return x + i; }
    };
  }
}

结果证明，只要有内部类，就会有闭包（Java 8只是让闭包实现起来更容易了）。在Java 8之前，x和i必须显式地声明为最终变量。而到了Java 8，内部类的规则也放宽了，可以包含“实际上的最终变量”。（未完待续）

---

本书特色

l  查漏宝典：涵盖Java关键特性的设计原理和应用方法

l  避坑指南：以产业实践的得失为鉴，指明Java开发者不可不知的设计陷阱

l  经典普适：值得不同层次的Java开发者反复研读

l  专家领读：4位一线业务专家、知名作译者帮你拆解书中难点，总结Java开发精要

值得一提的是，为了帮助新手加深理解，出版方邀请了4位从业10年以上知名作译者（DDD 专家张逸、服务端专家梁桂钊、软件系统架构专家王前明、译者陈德伟）为本书录制【精讲视频】和【导读指南】，该视频已在B站和图灵社区发布，感兴趣的朋友可以去看看。

读者福利    ：

618特别活动，基础卷限时5折，800多页软精装到手价64.9！！

618限时5折专享

想购买全套装书的读者，1400多页软精装到手价160

限量套装，售完为止

往期推荐

Bruce Eckel - 详解函数式编程（卷一）

如葑：阿里云原生网关Envoy Gateway实践

如何用研发效能搞垮一个团队

他教全世界程序员怎么写好代码，答案写在这里！

研发效能提升的实践框架、模式与反模式

为什么大数据平台要回归 SQL

聊聊大中型公司都热衷于造轮子的故事

被滥用的“架构师”！