关于Java方法重写的一些反思

最近在开发中遇到一个关于Java方法重写的一些问题，对于方法重写的用法以及可能导致的问题产生了一些思考，本文用于记录下这些想法。

问题场景

我们首先来看两段代码：

@Override
protected void onActivityResult(int requestCode, int resultCode, @Nullable Intent data) {
    super.onActivityResult(requestCode, resultCode, data);
    switch (requestCode){
        case TAKE_PHOTO_CODE:{
            //处理拍照得到的结果
            break;
        }
        case CHOOSE_FROM_ALBUM_CODE:{
            //处理相册选取到的结果
            break;
        }
    }
}

@Override
protected void onActivityResult(int requestCode, int resultCode, @Nullable Intent data) {
    switch (requestCode){
        case TAKE_PHOTO_CODE:{
            //处理拍照得到的结果
            break;
        }
        case CHOOSE_FROM_ALBUM_CODE:{
            //处理相册选取到的结果
            break;
        }
        default:{
            super.onActivityResult(requestCode, resultCode, data);
        }
    }
}

这两段代码是Android开发中处理Activity结果的示例。Android启动新页面后，新页面设置完结果返回的时候，旧页面可以从这个方法得到新页面的结果。来自不同页面的结果按照参数中的requestCode来区分，这个requestCode和启动新页面时传递的对应，也就是说一个requestCode标识一个页面请求和一个结果类型。例如，上面示例模拟的是常见APP中换用户头像的功能，结果有两种：1. 拍照得到的结果；2. 相册选取得到的结果。

上面两种方法就结果来说都是对的，但是表达的意义不同：第一种写法是纯粹地扩展父类的方法，父类干的事它都干；而第二种写法是改写父类的方法，相当于重定义并依赖了父类的行为，或者说对父类行为做了拦截、访问控制。

原本Activity类中默认实现是个空方法：

protected void onActivityResult(int requestCode, int resultCode, Intent data) {
}

这种情况下两种写法的行为差异完全可以忽略不计，但是实际开发中我们一般继承自FragmentActivity或AppCompatActivity，这两个类都对这个方法做了相应的实现，在这种情况下，第一种写法父类的实现一定会被执行，但是第二种写法可能将父类的实现短路了。这可能导致一些意料之外的问题，比如，Activity和Fragment都对某个requestCode进行处理，但第二种写法会导致Fragment的对应onActivityResult方法不会被掉用。

在实际开发中我们可能会编写一个BaseActivity，将一些方法实现一下并添加统计和日志，那么第二种写法也可能导致日志丢失的问题。

问题分析

这个问题让我联想到一个设计原则：里氏替换原则（Liskov Substitution principle）。这个原则说明：派生类（子类）对象可以在程序中代替其基类（超类）对象。这表示程序中任何父类对象可以出现的位置，子类的对象都可将其替代。进一步解读，就是意味着子类可以扩展父类的功能，但不能改变父类原有的功能。

这个原则考虑了安全性。编程时为了降低耦合度，通常面向抽象数据类型（例如接口、抽象类等）来编写，而父类在编写的时候也不会去考虑子类的实现，那么就要求子类的实现的时候需要顾及父类的运行。

那么当我们在重写父类方法的时候，情况就复杂了起来，具体分为以下几种情况：

1. 当父类代码和子类代码都是同一个人负责的时候，并且在代码同一项目、同一模块。这种情况比较安全，因为编写子类实现的人是完全了解并掌控父类实现的；
2. 当父类代码和子类代码是同一个人负责的时候，而代码位于不同项目。例如，一个人同时维护一个应用项目和一个独立框架。这种情况，就可能出隐患，因为随着项目进行，这个框架中的父类可能被多个应用项目使用，这个父类就可能无法兼顾多个项目的场景和用法，而导致子类实现中错误地改写父类的方法。
3. 当父类代码和子类代码时不同的人负责，且代码位于不同项目时，这种情况就比较危险了。因为父类实现的行为实现和行为变更很可能是不透明的、未知的，而且父类的实现可能不会顾及到子类的应用。那么当子类改写父类行为的时候，当父类行为发生变更，那么子类的实现很可能是有问题的。

方法与建议

针对上面所提到的三种情况，我思考了如下三个对应的建议：

1. 针对第一种安全的情况，尽量不改写父类方法，在子类和父类实现中尽量补充注释和注解说明；
2. 针对第二种有隐患的情况，尽量不改写父类方法，父类设计无法涵盖所有场景时，适当时候重构父类代码，而不是让子类通过“hack”的手段曲线救国。
3. 针对第三种危险的情况，一定不要改写父类方法，可以考虑在方法第一行就super调用。