聊聊关于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）。这个原则说明：派生类（子类）对象可以在程序中代替其基类（超类）对象。这表示程序中任何父类对象可以出现的位置，子类的对象都可将其替代。进一步解读，就是意味着子类可以扩展父类的功能，但不能改变父类原有的功能。

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

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

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

方法与建议

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

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

到此这篇关于聊聊关于Java方法重写的反思的文章就介绍到这了,更多相关Java方法重写内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论