在Java中,有一种惯例,将每个变量(局部变量或类)声明为final参数(如果它们确实是final的话)。

虽然这会使代码更加冗长,但这有助于容易阅读/掌握代码,也可以防止错误,因为意图被清晰地标记出来。

你对此有何看法?


当前回答

为事件监听器使用匿名本地类等是Java中的常见模式。 final关键字最常见的用法是确保偶数侦听器可以访问作用域内的变量。

但是,如果您发现自己被要求在代码中放入大量的最终语句。这可能是你做错事的好暗示。

上面的文章给出了这样一个例子:

public void doSomething(int i, int j) {
    final int n = i + j; // must be declared final

    Comparator comp = new Comparator() {
        public int compare(Object left, Object right) {
            return n; // return copy of a local variable
        }
    };
}

其他回答

Final应该总是用于常量。当定义变量的规则很复杂时,它甚至对于短期存在的变量(在单个方法中)也很有用。

例如:

final int foo;
if (a)
    foo = 1;
else if (b)
    foo = 2;
else if (c)
    foo = 3;
if (d)        // Compile error:  forgot the 'else'
    foo = 4;
else
    foo = -1;

我很少在方法或类上使用final,因为我喜欢允许人们重写它们。

否则,我只使用finally如果它是一个公共/私有静态最终类型SOME_CONSTANT;

在使用final关键字之前,您确实需要了解它的全部用途。它可以应用于变量、字段、方法和类,并对它们产生不同的影响

我建议你看看下面链接的文章,了解更多细节。

关于最后的关键字

我一直用final来表示对象属性。

final关键字在对象属性上使用时具有可见性语义。基本上,设置最终对象属性的值发生在构造函数返回之前。这意味着只要不让This引用脱离构造函数,并且对所有属性使用final,对象(在Java 5语义下)就可以保证正确构造,而且由于它也是不可变的,所以可以安全地发布到其他线程。

不可变对象不仅仅是关于线程安全。它们还使您更容易推断程序中的状态转换,因为可以更改的空间是故意的,如果始终使用,则完全限制在应该更改的内容上。

I sometimes also make methods final, but not as often. I seldomly make classes final. I generally do this because I have little need to. I generally don't use inheritance much. I prefer to use interfaces and object composition instead - this also lends itself to a design that I find is often easier to test. When you code to interfaces instead of concrete classes, then you don't need to use inheritance when you test, as it is, with frameworks such as jMock, much easier to create mock-objects with interfaces than it is with concrete classes.

我想我应该把大部分课程都定为期末考试,但我还没有养成这个习惯。

Final显然应该用在常量上,并加强不可变性,但在方法上还有另一个重要的用途。

Effective Java在这方面有一个完整的项目(项目15),指出了意外继承的陷阱。实际上,如果您没有为继承而设计和记录您的类,那么从它继承可能会带来意想不到的问题(该项目提供了一个很好的例子)。因此,建议在不打算继承的任何类和/或方法上使用final。

That may seem draconian, but it makes sense. If you are writing a class library for use by others then you don't want them inheriting from things that weren't designed for it - you will be locking yourself into a particular implementation of the class for back compatibility. If you are coding in a team there is nothing to stop another member of the team from removing the final if they really have to. But the keyword makes them think about what they are doing, and warns them that the class they are inheriting from wasn't designed for it, so they should be extra careful.