问题描述
我试图摆脱代码中的所有警告,并且今晚我注意到来自Netbeans的警告(不是编译器警告)。 采取以下代码:
class A {
public Void method1() {
return null;
}
public final Void method2() {
return null;
}
}
在method2()
Netbeans表示:
方法method2声明为final
但是那有什么问题呢? 在该类的实现中,它可以按预期工作:
class SubA extends A {
@Override
public Void method1() {
return super.method1();
}
@Override
public Void method2() { // <---- this throws an error
return super.method2();
}
}
那么为什么Netbeans抱怨呢?
注意:我知道我可以关闭警告(并且我知道如何),但是我想知道其背后的逻辑(如果有)。
1楼
在Netbeans 8+中:
-
转到
Tools --> Options
-
单击
Editor
顶部按钮 -
转到
Hints
选项卡。 -
确保在“
Language
组合框中选择了Java
。 -
在左树视图中,展开
Class Structure
。 -
检查是否检查了
Final method
。
您的警告很可能会发生,因为启用了上述配置,默认情况下不应启用该配置。
请注意,当您启用Final method
警告时,Netbeans会说:
报告方法的任何实例声明为final。 一些编码标准不鼓励最终课程。
因此,它实际上并没有尝试变得聪明。 它只是将所有这些报告为警告,因为有些人通常认为最终方法是不好的做法。
编辑:评论跟进
您最初的问题是:
那么为什么Netbeans抱怨呢?
答案很简单:因为您要求它在找到声明为final
的方法时抱怨。
但我想知道其背后的逻辑(如果有)。
您所暗示的方式没有逻辑。
它不会尝试分析时的具体使用final
是有道理的,当它不那么提醒你一下吧。
它只是一味地表扬你的警告你的所有用途的请求, final
一个方法修改。
然后由您决定是否需要采取警告措施。
分析在特定情况下使用final
修饰符是否合法的负担由您自己承担。
现在,在您的评论中,您现在说的问题是:
为什么要打扰我?
...这不是一个相同的问题,也没有在任何地方提到。
但是,既然您现在问,我就说这个问题没有明确的答案,而且很大程度上是基于意见的。
这就是为什么在Netbeans中默认情况下不启用警告的原因,因为有些人不为final
方法所困扰,并认为他们有合法用途。
有人认为使用final
是邪恶的。
例如,以下说:
邪恶的理由:
当用于标记类或方法时,
final
阻止或阻止重用。由于JitCompiler,将方法标记为
final
不太可能提高代码的运行效率。 已经具有有关哪些方法已被覆盖以及哪些方法已离开的信息。读代码的人必须再扫描一遍。 大写常量命名很常见,因此
final
是多余的。
这些人通常认为方法和类在默认情况下应保持“解锁”状态,以防万一有人决定将来需要通过重写方法来重写类的一部分。
相反,其他人(如我)则认为相反的做法更安全。
我更喜欢默认情况下无法覆盖我的类/方法,并且必须明确启用可以安全地覆盖类的哪些部分(如果有的话)。
这是C#等语言所采用的默认设置,默认情况下,您无法覆盖方法。
如果要启用覆盖,则必须通过将基类的方法标记为virtual
显式地实现。
关于哪个默认更好(Java或C#)更好的问题是许多热门辩论的主题。 请参见和的示例。
因此,您在辩论的哪一方面:
- 认为应该为继承/重写而打开类/方法的那一面,以防万一,或者
- 认为默认情况下应该锁定类/方法的一侧,并且仅在必要时才打开以进行继承/覆盖
……将确定您是否愿意让Netbeans警告您有关final
方法(与此有关的final
类)。
2楼
Netbeans并不是在“抱怨”它。 它只是吸引您的注意力。
is, 为说明这样做的原因下的 是,
最终方法[默认禁用]
报告方法的任何实例声明为final。 一些编码标准不鼓励最终课程。
从NetBeans 6.9开始
请看一下在评论部分中建议的 。
3楼
这只是一个警告。
只是说您已经声明了final
方法,但是将来要注意,不要有人重写此方法,否则会出现错误,因为不允许重写final
方法/类。
如果您这样设计,并且认为这是一个好的设计,那么就不要打扰这个警告; 否则,请更改您的设计。