自己怎样做网站,网页设计品牌,建设网站群,1 建设网站目的Java™8是第一个支持类型推断的 Java 版本#xff0c;而且它仅对 lambda 表达式支持此功能。在 lambda表达式中使用类型推断具有强大的作用#xff0c;它将帮助您做好准备以应对未来的 Java版本#xff0c;在今后的版本中还会将类型推断用于变量等更多可能。这里的诀窍在于恰…Java™8是第一个支持类型推断的 Java 版本而且它仅对 lambda 表达式支持此功能。在 lambda表达式中使用类型推断具有强大的作用它将帮助您做好准备以应对未来的 Java版本在今后的版本中还会将类型推断用于变量等更多可能。这里的诀窍在于恰当地命名参数相信 Java 编译器会推断出剩余的信息。大多数时候编译器完全能够推断类型。在它无法推断出来的时候就会报错。了解 lambda 表达式中的类型推断的工作原理至少查看一个无法推断类型的示例。即使如此也有解决办法。显式类型和冗余假设您询问某个人“您叫什么名字”他会回答“我名叫约翰”。这种情况经常发生但简单地说“约翰”会更高效。您需要的只是一个名称所以该句子的剩余部分都是多余的。不幸的是我们总是在代码中做这类多余的事情。Java 开发人员可以使用 forEach 迭代并输出某个范围内的每个值的双倍值如下所示IntStream.rangeClosed(1, 5).forEach((int number) - System.out.println(number * 2));rangeClosed 方法生成一个从 1 到 5 的 int 值流。lambda 表达式的唯一职责就是接收一个名为 number 的 int 参数使用PrintStream 的 println 方法输出该值的双倍值。从语法上讲该 lambda 表达式没有错但类型细节有些冗余。Java 8 中的类型推断当您从某个数字范围中提取一个值时编译器知道该值的类型为 int。不需要在代码中显式声明该值尽管这是目前为止的约定。在 Java 8 中我们可以丢弃 lambda 表达式中的类型如下所示IntStream.rangeClosed(1, 5).forEach((number) - System.out.println(number * 2));由于Java 是静态类型语言它需要在编译时知道所有对象和变量的类型。在 lambda 表达式的参数列表中省略类型并不会让 Java更接近动态类型语言。但是添加适当的类型推断功能会让 Java 更接近其他静态类型语言比如 Scala 或 Haskell。信任编译器如果您在 lambda 表达式的一个参数中省略类型Java 需要通过上下文细节来推断该类型。返回到上一个示例当我们在 IntStream 上调用 forEach 时编译器会查找该方法来确定它采用的参数。IntStream 的 forEach 方法期望使用函数接口 IntConsumer该接口的抽象方法 accept 采用了一个 int 类型的参数并返回 void。如果在参数列表中指定了该类型编译器将会确认该类型符合预期。如果省略该类型编译器会推断出预期的类型 —在本例中为 int。无论是您提供类型还是编译器推断出该类型Java 都会在编译时知道 lambda 表达式参数的类型。要测试这种情况可以在 lambda 表达式中引入一个错误同时省略参数的类型IntStream.rangeClosed(1, 5).forEach((number) - System.out.println(number.length() * 2));编译此代码时Java 编译器会返回以下错误Sample.java:7: error: int cannot be dereferenced.forEach((number) - System.out.println(number.length() * 2));^1 error编译器知道名为 number 的参数的类型。它报错是因为它无法使用点运算符解除对某个 int 类型的变量的引用。可以对对象执行此操作但不能对 int 变量这么做。类型推断的好处在 lambda 表达式中省略类型有两个主要好处键入的内容更少。无需输入类型信息因为编译器自己能轻松确定该类型。代码杂质更少 —(number) 比 (int number) 简单得多。此外一般来讲如果我们仅有一个参数省略类型意味着也可以省略 ()如下所示IntStream.rangeClosed(1, 5).forEach(number - System.out.println(number * 2));请注意您将需要为采用多个参数的 lambda 表达式添加括号。类型推断和可读性lambda 表达式中的类型推断违背了 Java 中的常规做法在常规做法中会指定每个变量和参数的类型。尽管一些开发人员辩称 Java 指定类型的约定让代码变得更可读、更容易理解但我认为这种偏好反映出一种习惯而不是必要性。以一个包含一系列转换的函数管道为例List result cars.stream().map((Car c) - c.getRegistration()).map((String s) - DMVRecords.getOwner(s)).map((Person o) - o.getName()).map((String s) - s.toUpperCase()).collect(toList());在这里我们首先提供了一组 Car 实例和相关的注册信息。我们获取每辆车的车主和车主姓名并将该姓名转换为大写。最后将结果放入一个列表中。这段代码中的每个 lambda 表达式都为其参数指定了一个类型但我们为参数使用了单字母变量名。这在 Java 中很常见。但这种做法不合适因为它丢弃了特定于域的上下文。我们可以做得比这更好。让我们看看使用更强大的参数名重写代码后发生的情况List result cars.stream().map((Car car) - car.getRegistration()).map((String registration) - DMVRecords.getOwner(registration)).map((Person owner) - owner.getName()).map((String name) - name.toUpperCase()).collect(toList());这些参数名包含了特定于域的信息。我们没有使用 s 来表示 String而是指定了特定于域的细节比如 registration 和name。类似地我们没有使用 p 或 o而是使用 owner 表明 Person 不只是一个人还是这辆车的车主。这个示例中的每个 lambda 表达式都比它所取代的表达式更好。在读取 lambda 表达式(例如 (Person owner) - owner.getName())时我们知道我们获得了车主的姓名而不只是随便某个人的姓名。命名参数Scala 和 TypeScript 等一些语言更加重视参数名而不是类型。在 Scala 中我们在定义类型之前定义参数例如通过编写def getOwner(registration: String)而不是def getOwner(String registration)类型和参数名都很有用但在 Scala 中参数名更重要一些。我们用 Java 编写 lambda 表达式时也可以考虑这一想法。请注意我们在 Java 中的车辆注册示例中丢弃类型细节和括号时发生的情况List result cars.stream().map(car - car.getRegistration()).map(registration - DMVRecords.getOwner(registration)).map(owner - owner.getName()).map(name - name.toUpperCase()).collect(toList());因为我们添加了描述性的参数名所以我们没有丢失太多上下文而且显式类型(现在是冗余内容)已悄然消失。结果是我们获得了更干净、更朴实的代码。类型推断的局限性尽管使用类型推断可以提高效率和可读性但这种技术并不适用于所有场合。在某些情况下完全无法使用类型推断。幸运的是您可以依靠 Java 编译器来获知何时出现这种情况。我们首先看一个测试编译器并获得成功的示例然后看一个测试失败的示例。最重要的是在两种情况下都能够相信编译器会按期望方式工作。扩展类型推断在我们的第一个示例中假设我们想创建一个 Comparator 来比较 Car 实例。我们首先需要一个 Car 类class Car {public String getRegistration() { return null; }}接下来我们将创建一个 Comparator以便基于 Car 实例的注册信息对它们进行比较public static Comparator createComparator() {return comparing((Car car) - car.getRegistration());}用作 comparing 方法的参数的 lambda 表达式在其参数列表中包含了类型信息。我们知道 Java 编译器非常擅长类型推断那么让我们看看在省略参数类型的情况下会发生什么如下所示public static Comparator createComparator() {return comparing(car - car.getRegistration());}comparing 方法采用了 1 个参数。它期望使用 Function super T, ? extends U 并返回 Comparator。因为 comparing是 Comparator 上的一个静态方法所以编译器目前没有关于 T 或 U 可能是什么的线索。为了解决此问题编译器稍微扩展了推断范围将范围扩大到传递给 comparing 方法的参数之外。它观察我们是如何处理调用comparing 的结果的。根据此信息编译器确定我们仅返回该结果。接下来它看到由 comparing 返回的 Comparator 又作为 Comparator 由 createComparator 返回 。注意了编译器现在已明白我们的意图它推断应该将 T 绑定到 Car。根据此信息它知道 lambda 表达式中的 car 参数的类型应该为 Car。在这个例子中编译器必须执行一些额外的工作来推断类型但它成功了。接下来让我们看看在提高挑战难度让编译器达到其能力极限时会发生什么。推断的局限性首先我们在前一个 comparing 调用后面添加了一个新调用。在本例中我们还为 lambda 表达式的参数重新引入显式类型public static Comparator createComparator() {return comparing((Car car) - car.getRegistration()).reversed();}借助显式类型此代码没有编译问题但现在让我们丢弃类型信息看看会发生什么public static Comparator createComparator() {return comparing(car - car.getRegistration()).reversed();}如您下面所见进展并不顺利。Java 编译器抛出了错误Sample.java:21: error: cannot find symbolreturn comparing(car - car.getRegistration()).reversed();^symbol:   method getRegistration()location: variable car of type ObjectSample.java:21: error: incompatible types: Comparator cannot be converted to Comparatorreturn comparing(car - car.getRegistration()).reversed();^2 errors像上一个场景一样在包含 .reversed() 之前编译器会询问我们将如何处理调用 comparing(car - car.getRegistration()) 的结果。在上一个示例中我们以 Comparable 形式返回结果所以编译器能推断出 T 的类型为 Car。但在修改过后的版本中我们将传递 comparable 的结果作为调用 reversed() 的目标。comparable 返回Comparablereversed() 没有展示任何有关 T 的可能含义的额外信息。根据此信息编译器推断 T 的类型肯定是 Object。遗憾的是此信息对于该代码而言并不足够因为 Object 缺少我们在 lambda 表达式中调用的 getRegistration() 方法。类型推断在这一刻失败了。在这种情况下编译器实际上需要一些信息。类型推断会分析参数、返回元素或赋值元素来确定类型但在上下文提供的细节不足时编译器就会达到其能力极限。能否采用方法引用作为补救措施在我们放弃这种特殊情况之前让我们尝试另一种方法不使用 lambda 表达式而是尝试使用方法引用public static Comparator createComparator() {return comparing(Car::getRegistration).reversed();}编译器对此解决方案非常满意。它在方法引用中使用 Car:: 来推断类型。结束语Java 8 为 lambda 表达式的参数引入了有限的类型推断能力在未来的 Java 版本中会将类型推断扩展到局部变量。现在应该学会省略类型细节并信任编译器这有助于您轻松步入未来的 Java 环境。依靠类型推断和适当命名的参数编写简明、更富于表达且更少杂质的代码。只要您相信编译器能自行推断出类型就可以使用类型推断。仅在您确定编译器确实需要您的帮助的情况下提供类型细节。原作者Venkat Subramaniam原文链接Java 8 习惯用语原出处 IBM Developer来源https://www.icode9.com/content-1-863301.html