final原理主義id:takahashikzn:20110122という記事があったので、私もだぁ〜と記事にしたくなった。
私も多々final宣言をする。
その中でも一番重要なメリットは、
『意図していない代入を自動的にチェックできる』ということ。
賛成です。が、私はあまりこう使い方はしていない。後で本当に代入をしないかどうかって意外に分からないからだ。後からやっぱり必要に迫られて書き換えることもある。
だからもう一つ付け加えて欲しい。
「意図した代入の忘れを自動的にチェックできる」ということ。
私が良くやる半端なfinal宣言の使い方は、コンストラクターで初期化すべき変数にfinal宣言をする。これにより初期化し忘れというミスを確実に防げます。
コンストラクター作成後、その変数がミュータブルならその都度final宣言を外します。
こうして私のクラスフィールドにはfinal宣言が多発します。
id:takahashikznさんの記事を読むまで、他人がソースを読んだときの足がかりになる、ということは考えたこともありませんでしたが、確かに最後までfinalが残っていればこいつは変更されなかったんだな〜というのがよく分かりますね。（オブジェクト自体はミュータブルだったりして中身が変更されてるということはありますが。）
ですが、何であれ結局のところfinal宣言とは誰かの為ではなく確実に自分の為に行う物だと思います。
証拠に私はチームでプログラム書いたことナース。（私はJAVA屋のくせにサーバーサイド何それおいしいの(^p^)というアホです。）
あと、テンプレートクラスなんかで、いちいちソース見ないとどの関数をオーバーライドして良くてオーバーライドしちゃいけないのか分からなくなるんですね。
そんなとき、関数にfinal宣言がついてるとEclipseさんがはじめから候補に入れてくれないので気が楽ですね。（まぁ、これは普通の使い方か。）
画像処理屋なので並列処理させる為に関数内部でfinal宣言もよくやります。（これは必要に迫られた宣言だから今回とは意図が違うか。）
というわけで、私はfinal宣言大好きです。
あと、もしかしたらJITコンパイラでいつの日かなんか最適化の恩恵受けられるかも、という淡い期待も抱けます。（※最近のは優秀だからfinalあろうが無かろうがちゃんと処理してくれています。）
