【编者按】本文作者为专注于自然语言处理多年的 Pierre-Yves Saumont，Pierre-Yves 著有30多本主讲 Java 软件开发的书籍，自2008开始供职于 Alcatel-Lucent 公司，担任软件研发工程师。
本文主要介绍了 Java 8 中的函数与原语，由国内 ITOM 管理平台 OneAPM 编译呈现。
Tony Hoare 把空引用的发明称为“亿万美元的错误”。也许在 Java 中使用原语可以被称为“百万美元的错误”。创造原语的原因只有一个：性能。原语与对象语言毫无关系。引入自动装箱和拆箱是件好事，不过还有很多有待发展。可能以后会实现（据说已经列入 Java 10的发展蓝图）。与此同时，我们需要对付原语，这可是个麻烦，尤其是在使用函数的时候。
Java 5/6/7的函数
在 Java 8之前，使用者可以创建下面这样的函数：
public interface Function<T, U> {
U apply(T t);
}
Function<Integer, Integer> addTax = new Function<Integer, Integer>() {
@Override
public Integer apply(Integer x) {
return x / 100 * (100 + 10); }
};
System.out.println(addTax.apply(100));
这些代码会产生以下结果：
110
Java 8 带来了 Function<T, U>接口和 lambda 语法。我们不再需要界定自己的功能接口, 而且可以使用下面这样的语法：
Function<Integer, Integer> addTax = x -> x / 100 * (100 + 10);
System.out.println(addTax.apply(100));
注意在第一个例子中，笔者用了一个匿名类文件来创建一个命名函数。在第二个例子中，使用 lambda 语法对结果并没有任何影响。依然存在匿名类文件, 和一个命名函数。
一个有意思的问题是：“x 是什么类型？”第一个例子中的类型很明显。可以根据函数类型推断出来。Java 知道函数参数类型是 Integer，因为函数类型明显是 Function<Integer, Integer>。第一个 Integer 是参数的类型，第二个 Integer 是返回类型。
装箱被自动用于按照需要将 int 和 Integer 来回转换。下文会详谈这一点。
可以使用匿名函数吗？可以，不过类型就会有问题。这样行不通：
System.out.println((x -> x / 100 * (100 + 10)).apply(100));
这意味着我们无法用标识符的值来替代标识符 addTax 本身（ addTax 函数)。在本案例中，需要恢复现在缺失的类型信息，因为 Java 8 无法推断类型。
最明显缺乏类型的就是标识符 x。可以做以下尝试：
System.out.println((Integer x) -> x / 100 * 100 + 10).apply(100));
毕竟在第一个例子中，本可以这样写：
Function<Integer, Integer> addTax = (Integer x) -> x / 100 * 100 + 10;
这样应该足够让 Java 推测类型，但是却没有成功。需要做的是明确函数的类型。明确函数参数的类型并不够，即使已经明确了返回类型。这么做还有一个很严肃的原因：Java 8对函数一无所知。可以说函数就是普通对象加上普通方法，仅此而已。因此需要像下面这样明确类型：
System.out.println(((Function<Integer, Integer>) x -> x / 100 * 100 + 10).apply(100));
否则，就会被解读为：
System.out.println(((Whatever<Integer, Integer>) x -> x / 100 * 100 + 10).whatever(100));
因此 lambda 只是在语法上起到简化匿名类在 Function（或 Whatever）接口执行的作用。它实际上跟函数毫不相关。
假设 Java 只有 apply 方法的 Function 接口，这就不是个大问题。但是原语怎么办呢？如果 Java 只是对象语言，Function 接口就没关系。可是它不是。它只是模糊地面向对象的使用（因此被称为面向对象）。Java 中最重要的类别是原语，而原语与面向对象编程融合得并不好。
Java 5 中引入了自动装箱，来协助解决这个问题，但是自动装箱对性能产生了严重限制，这还关系到 Java 如何求值。Java 是一种严格的语言，遵循立即求值规则。结果就是每次有原语需要对象，都必须将原语装箱。每次有对象需要原语，都必须将对象拆箱。如果依赖自动装箱和拆箱，可能会产生多次装箱和拆箱的大量开销。
其他语言解决这个问题的方法有所不同，只允许对象，在后台解决了转化问题。他们可能会有“值类”，也就是受到原语支持的对象。在这种功能下，程序员只使用对象，编译器只使用原语（描述过于简化，不过反映了基本原则）。Java 允许程序员直接控制原语，这就增大了问题难度，带来了更多安全隐患，因为程序员被鼓励将原语用作业务类型，这在面向对象编程或函数式程序设计中都没有意义。（笔者将在另一篇文章中再谈这个问题。）
不客气地说，我们不应该担心装箱和拆箱的开销。如果带有这种特性的 Java 程序运行过慢，这种编程语言就应该进行修复。我们不应该试图用糟糕的编程技巧来解决语言本身的不足。使用原语会让这种语言与我们作对，而不是为我们所用。如果问题不能通过修复语言来解决，那我们就应该换一种编程语言。不过也许不能这样做，原因有很多，其中最重要的一条是只有 Java 付钱让我们编程，其他语言都没有。结果就是我们不是在解决业务问题，而是在解决 Java 的问题。使用原语正是 Java 的问题，而且问题还不小。
现在不用对象，用原语来重写例子。选取的函数采用类型 Integer 的参数，返回 Integer。要取代这些，Java 有 IntUnaryOperator 类型。哇哦，这里不对劲儿！你猜怎么着，定义如下：
public interface IntUnaryOperator {
int applyAsInt(int operand);
...
}
这个问题太简单，不值得调出方法 apply。
因此，使用原语重写例子如下：
IntUnaryOperator addTax = x -> x / 100 * (100 + 10);
System.out.println(addTax.applyAsInt(100));
或者采用匿名函数：
System.out.println(((IntUnaryOperator) x -> x / 100 * (100 + 10)).applyAsInt(100));
如果只是为了 int 返回 int 的函数，很容易实现。不过实际问题要更加复杂。Java 8 的 java.util.function 包中有43种（功能）接口。实际上，它们不全都代表功能，可以分类如下：
- 21个带有一个参数的函数，其中2个为对象返回对象的函数，19个为各种类型的对象到原语或原语到对象函数。2个对象到对象函数中的1个用于参数和返回值属于相同类型的特殊情况。
- 9个带有2个参数的函数，其中2个为（对象，对象）到对象，7个为各种类型的（对象，对象）到原语或（原语，原语）到原语。
- 7个为效果，非函数，因为它们并不返回任何值，而且只被用于获取副作用。（把这些称为“功能接口”有些奇怪。）
- 5个为“供应商”，意思就是这些函数不带参数，却会返回值。这些可以是函数。在函数世界里，有些特殊函数被称为无参函数（表明它们的元数或函数总量为0）。作为函数，它们返回的值可能永远不变，因此它们允许将常量当做函数。在
Java 8，它们的职责是根据可变语境来返回各种值。因此，它们不是函数。
真是太乱了！而且这些接口的方法有不同的名字。对象函数有个方法叫 apply，返回数字化原语的方法被称为 applyAsInt、applyAsLong，或 applyAsDouble。返回 boolean 的函数有个方法被称为 test，供应商的方法叫做 get 或 getAsInt、getAsLong、 getAsDouble，或 getAsBoolean。（他们没敢把带有 test 方法、不带函数的 BooleanSupplier 称为“谓语”。笔者真的很好奇为什么！）
值得注意的一点，是并没有对应 byte、 char、 short 和 float 的函数，也没有对应两个以上元数的函数。
不用说，这样真是太荒谬了，然而我们又不得不坚持下去。只要 Java 能推断类型，我们就会觉得一切顺利。然而，一旦试图通过功能方式控制函数，你将会很快面对 Java 无法推断类型的难题。最糟糕的是，有时候 Java 能够推断类型，却会保持沉默，继续使用另外一个类型，而不是我们想用的那一个。
如何发现正确类型
假设笔者想使用三个参数的函数。由于 Java 8没有现成可用的功能接口，笔者只有一个选择：创建自己的功能接口，或者如前文（Java 8 怎么了之一）中所说，采取柯里化。创建三个对象参数、并返回对象的功能接口直截了当：
interface Function<T, U, V, R> {
R apply(T, t, U, u, V, v);
}
不过，可能出现两种问题。第一种，可能需要处理原语。参数类型也帮不上忙。你可以创建函数的特殊形式，使用原语，而不是对象。最后，算上8类原语、3个参数和1个返回值，只不过得到6561中该函数的不同版本。你以为甲骨文公司为什么没有在 Java 8中包含 TriFunction？（准确来说，他们只放了有限数量的 BiFunction，参数为 Object，返回类型为 int、long或double，或者参数和返回类型同为 int、long 或 Object，产生729种可能性中的9种结果。）
更好的解决办法是使用拆箱。只需要使用 Integer、Long、Boolean 等等，接下来就让 Java 去处理。任何其他行动都会成为万恶之源，例如过早优化（详见 http://c2.com/cgi/wiki?PrematureOptimization）。
另外一个办法（除了创建三个参数的功能接口之外）就是采取柯里化。如果参数不在同一时间求值，就会强制柯里化。而且它还允许只用一种参数的函数，将可能的函数数量限制在81之内。如果只使用 boolean、int、long 和double，这个数字就会降到25（4个原语类型加上两个位置的 Object 相当于5 x 5）。
问题在于在对返回原语，或将原语作为参数的函数来说，使用柯里化可能有些困难。以下是前文（Java 8怎么了之一）中使用的同一例子，不过现在用了原语：
IntFunction<IntFunction<IntUnaryOperator>>
intToIntCalculation = x -> y -> z -> x + y * z;
private IntStream calculate(IntStream stream, int a) {
return stream.map(intToIntCalculation.apply(b).apply(a));
}
IntStream stream = IntStream.of(1, 2, 3, 4, 5);
IntStream newStream = calculate(stream, 3);
注意结果不是“包含值5、8、11、14和17的流”，一开始的流也不会包含值1、2、3、4和5。newStream 在这个阶段并没有求值，因此不包含值。（下篇文章将讨论这个问题）。
为了查看结果，就要对这个流求值，也许通过绑定一个终端操作来强制执行。可以通过调用 collect 方法。不过在这个操作之前，笔者要利用 boxed 方法将结果与一个非终端函数绑定在一起。boxed 方法将流与一个能够把原语转为对应对象的函数绑定在一起。这可以简化求值过程：
System.out.println(newStream.boxed().collect(toList()));
这显示为：
[5,8, 11, 14, 17]
也可以使用匿名函数。不过，Java 不能推断类型，所以笔者必须提供协助：
private IntStream calculate(IntStream stream, int a) {
return stream.map(((IntFunction<IntFunction<IntUnaryOperator>>) x -> y -> z -> x + y * z).apply(b).apply(a));
}
IntStream stream = IntStream.of(1, 2, 3, 4, 5);
IntStream newStream = calculate(stream, 3);
柯里化本身很简单，只要别忘了笔者在其他文章中提到过的一点：
(x, y, z) -> w
解读为：
x -> y -> z -> w
寻找正确类型稍微复杂一些。要记住，每次使用一个参数，都会返回一个函数，因此你需要一个从参数类型到对象类型的函数（因为函数就是对象）。在本例中，每个参数类型都是 int，因此需要使用经过返回函数类型参数化的 IntFunction。由于最终类型为 IntUnaryOperator（这是 IntStream 类的 map 方法的要求），结果如下：
IntFunction<IntFunction<...<IntUnaryOperator>>>
笔者采用了三个参数中的两种，所有参数类型都是 int ，因此类型如下：
IntFunction<IntFunction<IntUnaryOperator>>
可以与使用自动装箱版本进行比较：
Function<Integer, Function<Integer, Function<Integer, Integer>>>
如果你无法决定正确类型，可以从使用自动装箱开始，只要替换上你需要的最终类型（因为它就是 map 参数的类型）：
Function<Integer, Function<Integer, IntUnaryOperator>>
注意，你可能正好在你的程序中使用了这种类型：
private IntStream calculate(IntStream stream, int a) {
return stream.map(((Function<Integer, Function<Integer, IntUnaryOperator>>) x -> y -> z -> x + y * z).apply(b).apply(a));
}
IntStream stream = IntStream.of(1, 2, 3, 4, 5);
IntStream newStream = calculate(stream, 3);
接下来可以用你使用的原语版本来替换每个 Function<Integer...，如下所示：
private IntStream calculate(IntStream stream, int a) {
return stream.map(((Function<Integer, IntFunction<IntUnaryOperator>>) x -> y -> z -> x + y * z).apply(b).apply(a)); }
然后是：
private IntStream calculate(IntStream stream, int a) { return stream.map(((IntFunction<IntFunction<IntUnaryOperator>>) x -> y -> z -> x + y * z).apply(b).apply(a)); }
注意，三个版本都可编译运行，唯一的区别在于是否使用了自动装箱。
何时匿名
在以上例子中可见，lambdas 很擅长简化匿名类的创建，但是不给创建的范例命名实在没有理由。命名函数的用处包括：
- 函数复用
- 函数测试
- 函数替换
- 程序维护
- 程序文档管理
命名函数加上柯里化能够让函数完全独立于环境（“引用透明性”），让程序更安全、更模块化。不过这也存在难度。使用原语增加了辨别柯里化函数类别的难度。更糟糕的是，原语并不是可使用的正确业务类型，因此编译器也帮不上忙。具体原因请看以下例子：
double tax = 10.24;
double limit = 500.0;
double delivery = 35.50;
DoubleStream stream3 = DoubleStream.of(234.23, 567.45, 344.12, 765.00);
DoubleStream stream4 = stream3.map(x -> {
double total = x / 100 * (100 + tax);
if ( total > limit) {
total = total + delivery;
}
return total;
});
要用命名的柯里化函数来替代匿名“捕捉”函数，确定正确类型并不难。有4个参数，返回 DoubleUnaryOperator，那么类型应该是 DoubleFunction<DoubleFunction<DoubleFunction<DoubleUnaryOperator>>>。不过，很容易错放参数位置：
DoubleFunction<DoubleFunction<DoubleFunction<DoubleUnaryOperator>>> computeTotal = x -> y -> z -> w -> {
double total = w / 100 * (100 + x);
if (total > y) {
total = total + z;
}
return total;
};
DoubleStream stream2 = stream.map(computeTotal.apply(tax).apply(limit).apply(delivery));
你怎么确定 x、y、z 和 w 是什么？实际上有个简单的规则：通过直接使用方法求值的参数在第一位，按照使用方法的顺序，例如，tax、limit、delivery 对应的就是 x、y 和 z。来自流的参数最后使用，因此它对应的是 w。
不过还存在一个问题：如果函数通过测试，我们知道它是正确的，但是没有办法确保它被正确使用。举个例子，如果我们使用参数的顺序不对：
DoubleStream stream2 = stream.map(computeTotal.apply(limit).apply(tax).apply(delivery));
就会得到：
[1440.8799999999999, 3440.2000000000003, 2100.2200000000003, 4625.5]
而不是：
[258.215152, 661.05688, 379.357888, 878.836]
这就意味着不仅需要测试函数，还要测试它的每次使用。如果能够确保使用顺序不对的参数不会被编译，岂不是很好？
这就是使用正确类型体系的所有内容。将原语用于业务类型并不好，从来就没有好结果。但是现在有了函数，就更多了一条不要这么做的理由。这个问题将在其他文章中详细讨论。
敬请期待
本文介绍了使用原语大概比使用对象更为复杂。在 Java 8中使用原语的函数一团糟,不过还有更糟糕的。在下一篇文章中，笔者将谈论在流中使用原语。
本文转自 OneAPM 官方博客
