我正试图摆脱代码中的所有警告,今晚我注意到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会抱怨?
注意:我知道我可以关闭警告(我知道如何),但我想知道它背后的逻辑(如果有的话)。
答案 0 :(得分:2)
在Netbeans 8 +中:
Tools --> Options
Editor
顶部按钮Hints
标签。Java
组合框中选择Language
。Class Structure
。Final method
。您的警告很可能发生,因为上面的配置已启用,默认情况下不应该这样。请注意当您启用Final method
警告时Netbeans所说的内容:
报告任何被宣布为final的方法实例。一些编码标准阻碍了最终的课程。
所以它确实没有尝试变聪明。它只是将它们全部报告为警告,因为有些人认为最终方法通常是不好的做法。
编辑:评论后续行动
你原来的问题是:
为什么Netbeans会抱怨?
答案就是答案:因为 你 要求它 随时投诉 它会找到一个声明为final
的方法。
但我想知道它背后的逻辑是什么(如果有的话)。
你所暗示的方式没有逻辑。它不会尝试分析 时final
的特定用途是否有意义,以及当它没有警告你时。 它只是盲目地尊重您在方法上警告 所有 使用final
修饰符的请求。然后由您决定是否需要对警告采取措施。分析在特定情况下使用final
修饰符是否合法的负担留给您。
现在,在您的评论中,您现在说您的问题是:
为什么这会打扰我?
......这不是同一个问题,并没有在任何地方说明。但是,既然你现在问,我会说这个问题没有明确的答案,而且主要是基于意见的。这就是Netbeans默认情况下未启用警告的原因,因为有些人不会被final
方法困扰,并认为它们具有合法用途。
有些人认为使用final
是邪恶的。例如,以下article说:
邪恶的案例:
final
在用于标记类或方法时阻碍或阻止重用。将方法标记为
final
不太可能提高自JitCompiler以来代码的运行时效率?已经有关于哪些方法已被覆盖以及哪些方法已经离开的信息。- 醇>
读取代码的人必须再扫描一遍。以大写形式命名常量非常常见,因此
final
是多余的。
那些同样的人通常会觉得方法和课程应该被解开&#34;解锁&#34;默认情况下,如果有人通过在将来覆盖某个方法来决定他们需要覆盖某个类的一部分。
相比之下,其他人(像我一样)认为相反的是更安全。我更喜欢默认情况下无法覆盖我的类/方法,并且我必须明确地允许安全地覆盖类的哪些部分(如果有的话)。这是C#等语言的默认设置,默认情况下,您不能覆盖方法。如果要启用覆盖,则必须明确标记基类&#39;方法virtual
。
哪个默认更好(Java或C#&#39; s)的问题是许多热门辩论的主题。有关示例,请参阅here和here。
那么,你正在辩论的哪一方:
...将确定您是否会关心Netbeans警告您final
方法(以及此类final
类)。
答案 1 :(得分:1)
Netbeans并没有抱怨它&#34;。它只是引起你的注意力。
类结构下here所述的原因是,
最终方法[默认禁用]
报告任何被宣布为final的方法实例。一些编码标准阻碍了最终的课程。
自NetBeans 6.9
以来
请查看评论部分this article建议的Mathias Begert。
答案 2 :(得分:1)
这只是一个警告。
这只是说你已经声明了final
方法,但是请注意以后某人不应该覆盖此方法,否则你会收到错误,因为覆盖final
方法/不允许上课。
如果你的设计是这样的,并且你认为这是一个很好的设计,那就不要打扰这个警告;否则,改变你的设计。