Java中super调用的最佳实践？为何重写sendRequest而非新增方法？

好问题！咱们先拆分来看，先聊聊Java里调用super的最佳实践，再针对你给出的代码场景分析两种方案的差异。

一、Java中调用super的最佳实践 #

• 仅在需要复用父类逻辑时调用：不要为了调用而调用，只有当你需要在子类逻辑中复用父类的实现，再做扩展时才使用super，避免无意义的调用增加代码冗余。
• 控制调用时机：通常建议在方法开头调用super（比如需要先执行父类的校验、初始化逻辑），或者在方法结尾（当父类逻辑依赖子类扩展后的状态时），尽量避免在方法中间插入super调用，防止逻辑流程混乱，难以维护。
• 构造器中调用super()要规范：构造器中调用父类构造器必须是第一行代码，而且要避免在构造器中调用父类的非final方法——因为子类可能还未完成初始化，调用非final方法可能导致未初始化的成员被访问，引发异常。
• 明确重载方法的调用：当父类有多个重载的同名方法时，要确保你调用的super.xxx()是正确的那个，通过参数匹配明确指定，避免因自动装箱/拆箱或参数类型兼容导致的调用错误。
• 避免复制父类逻辑：如果只是要扩展父类方法的功能，不要把父类的代码复制到子类再修改，而是通过super调用父类方法后，再添加子类自己的逻辑，这样父类后续的逻辑变更能自动同步到子类。

二、为什么选择重写sendRequest而非新增Send方法？ #

针对你给出的代码场景，重写sendRequest是更符合面向对象设计原则的选择，主要原因如下：

1. 保证多态性的正常生效 #

如果你的子类是作为父类的实现被使用（比如用父类引用指向子类实例），那么调用sendRequest时会自动触发子类的重写逻辑。但如果是新增Send方法，父类引用无法调用到这个新方法，调用方还是会执行父类原有的sendRequest，直接跳过你添加的日志/追踪逻辑，完全达不到你的预期。

举个实际的例子：

// 父类
public class BaseRequestSender {
    public boolean sendRequest(Object... params) {
        // 父类的请求发送核心逻辑
        return true;
    }
}

// 重写方法的子类
public class TracingRequestSender extends BaseRequestSender {
    @Override
    public boolean sendRequest(Object... params) {
        if (!super.sendRequest(params)) {
            return false;
        }
        // 追踪日志逻辑
        System.out.println("Request traced: params=" + Arrays.toString(params));
        return true;
    }
}

// 使用时
BaseRequestSender sender = new TracingRequestSender();
sender.sendRequest("param1", "param2"); // 自动触发追踪日志，符合预期

// 新增方法的子类
public class TracingRequestSender extends BaseRequestSender {
    public boolean Send(Object... params) { // 注意：Java命名规范是小驼峰，这里写法也不规范
        if (!super.sendRequest(params)) {
            return false;
        }
        // 追踪日志逻辑
        System.out.println("Request traced: params=" + Arrays.toString(params));
        return true;
    }
}

// 使用时，父类引用无法调用Send方法
BaseRequestSender sender = new TracingRequestSender();
sender.sendRequest("param1", "param2"); // 不会执行追踪日志，完全达不到目的

2. 保持接口一致性 #

如果父类（或者子类实现的接口）把sendRequest定义为标准的业务方法，重写它能保持对外的接口统一。调用方不需要记住额外的方法名，减少认知负担，同时也符合里氏替换原则——子类可以无缝替换父类，调用方的代码不需要做任何修改就能享受到子类的增强功能。

3. 提升代码维护性 #

如果后续父类的sendRequest方法有逻辑变更（比如新增了参数校验、异常处理），重写的方式会自动继承这些变更（因为你调用了super.sendRequest）。但如果是新增方法，你需要手动同步新方法里的父类调用逻辑，很容易遗漏，导致子类的增强逻辑和父类核心逻辑脱节。

4. 保证语义一致性 #

sendRequest是原本的业务方法名，重写它意味着你是在增强这个方法的原有功能，语义清晰。而新增一个类似的Send方法（还不符合Java小驼峰的命名规范）会造成语义混淆，其他开发者看代码时会疑惑：为什么有两个功能类似的方法？哪个才是正确的调用入口？反而增加了代码的理解成本。

当然，如果你的业务需求是同时保留父类原方法的纯净版本，并且需要提供一个带增强逻辑的版本，那新增方法可能是合理的选择，但这种场景非常少见——大多数情况下，重写sendRequest并通过super调用父类逻辑是更优的方案。

内容的提问来源于stack exchange，提问作者陈玉军