Java函数式与OOP范式对比：行为抽象方式的抉择

问题背景 #

我需要在类中抽象出一种特定行为，目前有两种实现思路：

选项1：子类化继承重写 #

class SomeClass {
    public Output behaviour(Input input) {
        // 基础行为实现
    }
}

class SomeOtherClass extends SomeClass {
    @Override
    public Output behaviour(Input input) {
        // 重写后的行为
    }
}

选项2：外部注入函数（无需子类化） #

class SomeClass {
    public Output behaviour(Function<Input, Output> function, Input input) {
        return function.apply(input);
    }
}

问题：自Java 8+全面支持函数式编程范式以来，行为抽象的常规流程是否发生变化？哪种行为抽象方式更优？若需视场景而定，各自的适用情况是什么？

解答 #

Java 8+ 对行为抽象流程的影响 #

Java 8引入的Lambda表达式和函数式接口，确实给行为抽象带来了更灵活的可选方案，但并没有完全替代传统的继承重写模式——它只是扩充了我们的工具库。在Java 8之前，要实现行为抽象，除了继承，就只能靠冗余的匿名内部类；而函数式编程的支持让我们可以把行为作为"一等公民"传递，大幅简化了动态替换行为的代码，让行为抽象的流程多了一种轻量化的选择。

两种方式的对比与适用场景 #

没有绝对的"更优"，只有更贴合业务场景的选择：

子类化继承重写（选项1）的适用场景

• 行为与类的核心职责强绑定：如果这个行为是类的"本质属性"的一部分，比如Animal类的makeSound()，不同动物的叫声是其固有特性，用继承重写更符合面向对象的"is-a"关系，代码可读性和直观性更强。
• 需要复用父类的其他逻辑：如果子类不仅要重写目标行为，还要依赖父类的其他方法、属性或内部状态，继承可以自然地复用这些逻辑，避免重复编写相似代码。
• 行为变化较少，且编译时可确定：如果行为的实现是相对固定的几种，比如预定义的子类实现，继承模式的结构更清晰，后续维护和扩展也更有条理。

函数式注入（选项2）的适用场景

• 行为需要动态替换：如果同一个类在不同业务场景下需要不同的行为实现，比如一个DataProcessor类，需要根据不同的业务规则切换数据转换逻辑，用函数注入可以在运行时直接传入Lambda表达式，不需要创建多个子类。
• 行为是独立的小逻辑单元：当行为只是类的一个"附属操作"，而非核心职责时，比如集合的forEach操作、Stream中的过滤/映射逻辑，把行为作为参数传递更简洁，也符合"组合优于继承"的设计原则。
• 避免类膨胀：如果需要几十种甚至更多不同的行为实现，用继承会导致大量子类，而函数式注入只需要不同的Lambda或方法引用，代码更简洁，也更容易管理。

实用小技巧 #

在实际开发中，我们也可以结合两种方式，兼顾稳定性和灵活性：比如父类提供一个默认的行为实现，同时允许通过注入函数来覆盖它。示例代码如下：

class SomeClass {
    // 默认行为实现
    public Output behaviour(Input input) {
        // 默认逻辑
    }

    // 允许注入自定义行为，优先使用自定义逻辑
    public Output behaviour(Function<Input, Output> customFunction, Input input) {
        return customFunction != null ? customFunction.apply(input) : behaviour(input);
    }
}

内容的提问来源于stack exchange，提问作者Harshit