为什么最终参数修饰符不能在具体的实现方法签名中继承?

问题描述 投票:3回答:3

考虑到我们有这样的方法签名

public abstract class BaseClass {
    protected abstract void doStuff(final MyArg arg);
}

为什么具体实现不再需要在方法签名中实现final修饰符?

public class ConcreteClass extends BaseClass {

    @Override
    protected void doStuff(MyArg arg) {
        // TODO
    }

}

现在,我知道您仍然可以在具体签名中使用参数final,但是为什么不强迫您这样做呢?跳过它的原因是什么,还有一个额外的问题,为什么Intellij这样的代码生成器默认也跳过它?

java intellij-idea
3个回答
4
投票

参数是否为final对调用方没有影响,就像调用方不需要知道方法的局部变量是否为final一样。它不是方法合同的一部分;参数的final修饰符出现在签名中的唯一原因是因为它是声明该参数的位置。

具体的重写方法不需要“履行” final修饰符,因为没有义务履行。


6
投票

参数是否为final绝对对方法的调用者没有影响。

纯粹是一个标志,指示在方法主体内不应更改参数。

由于任何此类更改仅在方法主体内可见,因此调用者无法关心(或观察)参数是否为最终参数。

A methods signature仅取决于参数类型。它不依赖于参数namesfinal关键字的存在。


4
投票

接口的实现必须具有与接口相同或更大的签名。

根据Java Language Specification

两个方法或构造函数(M和N,如果它们具有相同的签名,具有相同的名称,相同的类型参数(如果有的话)(第8.4.4节),并且,在将N的形式参数类型调整为类型之后M的参数,相同的形式参数类型。

[方法m1的签名是a的签名的子签名方法m2(如果有):

m2 has the same signature as m1, or

the signature of m1 is the same as the erasure (§4.6) of the signature of m2.

因此,关键字final对方法签名的相等性没有任何影响。

© www.soinside.com 2019 - 2024. All rights reserved.