Java函数式编程实践：为何应优先选择Lambda而非匿名类？

在 Java 8 及之后的版本中，当我们需要创建函数式接口（即只有一个抽象方法的接口）的实例时，一个明确的最佳实践是：优先使用 Lambda 表达式，而不是传统的匿名内部类。

Lambda与匿名类对比

在 Java 8 之前，如果想即时创建一个函数式接口的实例，匿名内部类是标准做法。尽管它实现了功能，但其语法极其冗长，引入了大量样板代码，不必要地增加了代码体积并降低了可读性。

来看一个经典的排序例子。假设有一个字符串列表，我们想根据字符串长度进行排序。

使用传统匿名类的写法是这样的：

List<String> words = Arrays.asList("apple", "banana", "cherry");

// 使用匿名类
Collections.sort(words, new Comparator<String>() {
    @Override
    public int compare(String s1, String s2) {
        return Integer.compare(s1.length(), s2.length());
    }
});

可以看到，为了定义一个小小的比较逻辑，我们不得不写很多“仪式性”的代码：new 关键字、接口类型声明、方法重写注解等。

现在，使用 Lambda 表达式来实现完全相同的功能：

Collections.sort(words, (s1, s2) -> Integer.compare(s1.length(), s2.length()));

只需要一行代码，清晰且直接地表达了我们的意图：“比较两个字符串的长度”。编译器能够自动推导出参数 s1 和 s2 的类型为 String。实际上，在大多数情况下，我们都应该省略参数类型，让编译器来做这个工作，除非显式写出类型能让代码更易于理解。

我们甚至可以让它变得更简洁，结合 Java 8 引入的方法引用：

words.sort(Comparator.comparingInt(String::length));

通过 Comparator.comparingInt 这个静态工厂方法和 String::length 方法引用，意图表达得淋漓尽致：根据字符串的长度进行比较。这种写法的可读性和简洁性达到了一个新的高度。

何时仍需使用匿名类？

尽管 Lambda 表达式的优势巨大，但它并非万能的“银弹”。在以下几种特定场景下，匿名类仍然是必要的选择：

1. 处理非函数式接口：如果你需要实例化的类型是一个抽象类，或者是一个包含多个抽象方法的接口（不符合函数式接口的定义），那么 Lambda 将无法使用，匿名类是你唯一的选择。

2. 需要访问“自己”：在 Lambda 表达式内部，this 关键字指向的是其所在的外部类。如果你的代码块需要引用匿名类实例自身（例如，调用当前实例的另一个方法），那么就必须使用匿名类，因为匿名类有自己的 this 指向自身实例。

3. 逻辑过于复杂：Lambda 表达式的设计初衷是用于表示小巧、单一的函数对象。它应该非常简短——理想情况是一行，最多不超过三行。如果一个函数对象的实现逻辑非常复杂，以至于塞进 Lambda 后会严重影响可读性，那么更好的做法是将其抽取为一个独立的、有名称的方法，或者退而求其次，使用结构更清晰的匿名类，以便于后续的阅读和维护。

总结

总而言之，Lambda 表达式极大地简化了函数式接口实例的创建，让代码变得更紧凑、意图更明确。对于大多数日常编程场景，我们应该养成优先使用 Lambda 的习惯。当然，了解匿名类仍然适用的边界情况同样重要，这能帮助我们在正确的场景选择正确的工具。在 Java 开发社区，比如云栈社区中，关于如何优雅地使用 Lambda 和 Stream API 一直是热门的技术讨论话题。持续探索和实践这些现代特性，是编写高质量、现代化 Java 代码的关键一步。