コンパイラが Java の final キーワードをどのように解釈するかは知っていますが、私たちプログラマーはその意味をどのように解釈すればよいでしょうか? それは次のとおりです。
1) この変数は変更できません (たとえば、内部クラスで使用されます)。
また
2）この変数を変更する予定はありません（メンバー変数の最適化の利点があるかもしれません）。
私の意見では、キーワードの価値を下げ、実際には変更できない値を非表示にします。変数を final と宣言しても、パフォーマンス上の利点はありますか?
デフォルトですべてが最終的であることは良いことです。不変性に基づいてコードをモデル化できるほど、推論が容易になる傾向があります。
私の意見では、使用finalはパフォーマンスに関するものではありません。これは、コードの残りの部分 (この変数を変更するものは何もない) についてアサーションを作成することであり、これは読者がコードを理解するのに役立ち、コンパイラーによってチェックされます。
編集：上記はフィールドに対する私の見解です。ローカル変数 (パラメーターを含む) については、個人的finalには、変数が匿名の内部クラスで使用される場合にのみ使用します。これは、次の理由でフィールドとは異なります。
finalキーワードは放棄する必要があり、適用可能なすべてのケースで標準にする必要があり、finality は次のようなキーワードでのみ取り消し可能にする必要があります。
this_variable_will_change_unexpectedly_behind_your_back
このキーワードはどの IDE でもオートコンプリートされるべきではなく、Ctrl-V で挿入することもできません。
これについては少し前に記事を書きました。
Finalはコードを読むのに役立ちます:
final を使用すると、コンパイラにコードについて何かを伝えることができ、見返りに役立ちます。
Jon が既に言ったことに多くを追加することはできませんが、完全を期すために、JLS 17.5.3は最終フィールドも最適化につながる可能性があると述べています。
フィールド宣言で final フィールドがコンパイル時の定数式 (§15.28) に初期化されている場合、その final フィールドの使用はコンパイル時に定数式の値に置き換えられるため、final フィールドへの変更は観察されない場合があります。 .
2 番目のオプションはセーフガードです。誤って変更したり再割り当てしたりするのを防ぎます。そのため、提供すると便利であり、その変数を変更したい場合は削除できます。
価値がないと思う理由がわかりません。
すべての最終変数を見ると、クラスが不変であることを意味します。不変クラスは本質的にスレッドセーフであるため、これは良いことです。
すべての変数をfinal切り下げfinalキーワードではないとして宣言します。これは、開発者がアプリケーションをデバッグする際に、特にアプリケーションのマルチスレッド環境で変数が変更される可能性を排除するのに役立ちます。
effectively final variableJava 8 リリースでは、「 」という概念がもう 1 つあります。
ラムダ式から参照されるローカル変数は final または実質的に final でなければなりません
変数は、ローカル ブロックでの初期化後に変更されていない場合、有効な finalと見なされます。これは、実質的に final でなければならない場合、匿名クラスまたはラムダ式内で final キーワードなしでローカル変数を使用できるようになったことを意味します。
有効な final を final 変数として宣言したくない場合、ラムダ式/匿名クラスを使用している場合、この新しい機能が役立ちます。変数のfinalキーワードの宣言を避けることができます。effective finalこの記事を見てください
誰も値を変更できないように最終変数が使用されるのは本当です。Javaでは定数として機能します。
例を挙げましょう
他の人も使用できるパッケージを 1 つ作成しましたが、適切に実行するために設定する必要がある構成変数がいくつかあります。ログインパッケージとしましょう。したがって、次のような暗号化オプションはほとんどありません
暗号化方法 = HASH_ENCRYPTION
また
暗号化方法 = SYMMETRIC_ENCRYPTION
整数 1、2、3 を渡す代わりに、最終的な変数を定義して、開発者がより読みやすい形式にすることができます。もちろん、ユーザーに変更してほしくないので、最終的に保持します。そうしないと、内部ロジックが壊れる可能性があります。