为什么我应该在Java的方法参数上使用关键字“final”?

当final关键字用于方法参数时，我不明白它在哪里真正方便。

如果我们排除匿名类的使用，可读性和意图声明，那么它对我来说几乎毫无价值。

强制某些数据保持不变并不像看上去那么有力。

如果参数是一个原语，那么它将没有任何影响，因为参数是作为值传递给方法的，在作用域之外更改它不会产生任何影响。如果我们通过引用传递参数，那么引用本身就是一个局部变量，如果从方法内部更改引用，那么从方法作用域外部更改引用不会产生任何影响。

考虑下面的简单测试示例。这个测试通过了，尽管该方法改变了给它的引用值，但它没有任何影响。

public void testNullify() {
    Collection<Integer> c  = new ArrayList<Integer>();      
    nullify(c);
    assertNotNull(c);       
    final Collection<Integer> c1 = c;
    assertTrue(c1.equals(c));
    change(c);
    assertTrue(c1.equals(c));
}

private void change(Collection<Integer> c) {
    c = new ArrayList<Integer>();
}

public void nullify(Collection<?> t) {
    t = null;
}

当前回答

就我个人而言，我不会在方法参数上使用final，因为它给参数列表增加了太多的混乱。我更倾向于强制方法参数不通过Checkstyle之类的东西改变。

对于局部变量，我尽可能使用final，我甚至让Eclipse在个人项目的设置中自动执行该操作。

我当然喜欢更强的语言，比如C/ c++ const。

2009-02-01 11:01:50

其他回答

我总是在参数上使用final。

加了那么多吗?不是真的。

我会把它关掉吗?不。

原因:我发现了3个错误，人们编写了草率的代码，未能在访问器中设置成员变量。所有的漏洞都被证明很难找到。

我希望在未来的Java版本中将此设置为默认值。通过值/引用传递的东西绊倒了很多初级程序员。

还有一件事…我的方法倾向于参数数量较少，因此方法声明上的额外文本不是问题。

2009-02-01 15:20:09

简短的回答:最终有一点帮助，但是……在客户端使用防御性编程。

实际上，final的问题在于它只强制引用不变，允许被引用的对象成员发生变化，而调用者不知道。因此，在这方面的最佳实践是在调用方进行防御性编程，创建深度不可变的实例或对象的深度副本，这些实例或对象有被肆无忌惮的api窃取的危险。

2016-06-20 21:04:21

在参数声明中添加final的另一个原因是，它有助于识别作为“Extract Method”重构的一部分需要重命名的变量。我发现，在开始大型方法重构之前向每个参数添加final可以快速告诉我在继续之前是否有任何需要解决的问题。

但是，我通常会在重构结束时将它们作为多余的部分删除。

2009-02-02 05:42:40

在方法形参中使用final与调用方的实参发生了什么无关。它只是为了将其标记为在该方法中没有更改。当我尝试采用更函数式的编程风格时，我看到了其中的价值。

2009-02-01 10:13:55

我从不在参数列表中使用final，它只会像之前的受访者所说的那样增加混乱。另外，在Eclipse中，你可以设置参数赋值来生成错误，所以在参数列表中使用final对我来说似乎是多余的。有趣的是，当我启用Eclipse参数赋值设置时，它生成了一个错误，捕获了这段代码(这只是我记住流程的方式，而不是实际的代码)。：－

private String getString(String A, int i, String B, String C)
{
    if (i > 0)
        A += B;

    if (i > 100)
        A += C;

    return A;
}

唱反调，这样做到底有什么错?

2013-01-07 16:08:33

为什么我应该在Java的方法参数上使用关键字“final”?

推荐文章

最新文章

标签