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を使用します。

変数が静的変数、メンバー変数、ローカル変数、引数/パラメーター変数のいずれであっても、効果はまったく同じです。

例

実際の効果を見てみましょう。

2つの変数（argとx）の両方に異なるオブジェクトを再割り当てできる、この単純な方法を考えてみましょう。

// Example use of this method: 
//   this.doSomething( "tiger" );
void doSomething( String arg ) {
  String x = arg;   // Both variables now point to the same String object.
  x = "elephant";   // This variable now points to a different String object.
  arg = "giraffe";  // Ditto. Now neither variable points to the original passed String.
}

ローカル変数をfinalとしてマークします。これにより、コンパイラエラーが発生します。

void doSomething( String arg ) {
  final String x = arg;  // Mark variable as 'final'.
  x = "elephant";  // Compiler error: The final local variable x cannot be assigned. 
  arg = "giraffe";  
}

代わりに、パラメーター変数をfinalとしてマークしましょう。これもコンパイラエラーになります。

void doSomething( final String arg ) {  // Mark argument as 'final'.
  String x = arg;   
  x = "elephant"; 
  arg = "giraffe";  // Compiler error: The passed argument variable arg cannot be re-assigned to another object.
}

この話の教訓：

変数が常に同じオブジェクトを指すようにする場合は、変数にfinalをマークします。

引数を再割り当てしない

（任意の言語での）良いプログラミング方法として、呼び出しメソッドによって渡されたオブジェクト以外のオブジェクトにパラメーター/引数変数を再割り当てしないでください。上記の例では、決して行を書かないでくださいarg =。人間は間違いを犯し、プログラマーも人間なので、コンパイラーに助けを求めましょう。コンパイラがそのような再割り当てを見つけてフラグを付けることができるように、すべてのパラメータ/引数変数を「最終」としてマークします。

振り返ってみると

他の回答で述べたように、配列の終わりを超えて読み取るなどの愚かな間違いをプログラマーが回避できるようにするJavaの元の設計目標を考えると、Javaはすべてのパラメーター/引数変数を「最終」として自動的に強制するように設計されているはずです。つまり、引数は変数であってはなりません。しかし後知恵は20/20のビジョンであり、Javaの設計者たちは当時、彼らの手を完全に満たしていました。

それで、常にfinalすべての引数に追加しますか？

final宣言されるすべてのメソッドパラメータに追加する必要がありますか？

• 理論的にはそうです。
• 実際には、違います。
  ➥ finalメソッドのコードが長いか複雑な場合にのみ追加します。引数がローカル変数またはメンバー変数と間違えられ、場合によっては再割り当てされる可能性があります。

引数を再割り当てしないという慣習に慣れればfinal、それぞれにを追加する傾向があります。しかし、これは退屈で、宣言を読みにくくしています。

引数が明らかに引数であり、ローカル変数でもメンバー変数でもない短い単純なコードの場合、私はわざわざを追加しませんfinal。コードが非常に明白で、私や他のプログラマーがメンテナンスやリファクタリングを行ったり、引数変数を引数以外のものと誤って間違えたりする可能性がない場合は、気にしないでください。私自身の作業でfinalは、引数がローカル変数またはメンバー変数と間違えられる可能性がある、より長いコードまたはより複雑なコードにのみ追加します。

完全性のために追加された別のケース

public class MyClass {
    private int x;
    //getters and setters
}

void doSomething( final MyClass arg ) {  // Mark argument as 'final'.

   arg =  new MyClass();  // Compiler error: The passed argument variable arg  cannot be re-assigned to another object.

   arg.setX(20); // allowed
  // We can re-assign properties of argument which is marked as final
 }

変数が変化しないことを（読みやすくするために）明示的にするとよい場合があります。以下は、使用finalすることで頭痛の種を減らすことができる簡単な例です。

public void setTest(String test) {
    test = test;
}

セッターで「this」キーワードを忘れた場合、設定する変数は設定されません。ただし、finalパラメーターでキーワードを使用した場合、バグはコンパイル時に検出されます。

はい、匿名クラス、読みやすさ、意図の宣言を除いて、ほとんど価値がありません。これら3つのことは価値がありませんか？

個人的にはfinal、匿名の内部クラスで変数を使用していない限り、ローカル変数とパラメーターには使用しない傾向がありますが、パラメーター値自体が変更されないことを明確にしたい人のポイントは確かにわかります（それが参照するオブジェクトがその内容を変更する場合）。それが読みやすさを増すと思う人にとって、私はそれを行うのは完全に合理的なことだと思います。

誰かが実際にデータを一定の方法で維持しないと主張している場合、あなたの主張はより重要になります。しかし、そのような主張を見たことを思い出せません。finalそれが実際よりも効果があることを示唆する開発者のかなりの団体がいることを示唆していますか？

編集：私は本当にこれらすべてをMonty Pythonリファレンスで要約するべきでした; この質問は、「ローマ人は私たちのためにこれまで何をしたのですか？」

ジョンがすでに述べた、ファイナルを使用する必要がある1つのケースについて少し説明しましょう。

メソッドで匿名の内部クラスを作成し、そのクラス内でローカル変数（メソッドパラメーターなど）を使用すると、コンパイラーはパラメーターをfinalにするように強制します。

public Iterator<Integer> createIntegerIterator(final int from, final int to)
{
    return new Iterator<Integer>(){
        int index = from;
        public Integer next()
        {
            return index++;
        }
        public boolean hasNext()
        {
            return index <= to;
        }
        // remove method omitted
    };
}

ここでfromand toパラメータはfinalである必要があるため、匿名クラス内で使用できます。

この要件の理由は次のとおりです。ローカル変数はスタック上に存在するため、メソッドが実行されている間だけ存在します。ただし、匿名クラスのインスタンスはメソッドから返されるため、ずっと長く存続する可能性があります。スタックは後続のメソッド呼び出しで必要になるため、保持することはできません。

したがって、Javaが代わりに行うのは、これらのローカル変数のコピーを隠しインスタンス変数として匿名クラスに配置することです（バイトコードを調べると、それらを確認できます）。しかし、それらが最終的でない場合、匿名クラスと、他の1つが変数に加える変更を参照するメソッドを期待するかもしれません。2つのコピーではなく1つの変数しかないという幻想を維持するために、それは最終的なものでなければなりません。

私は常にfinalパラメータを使用しています。

それだけ追加されますか？あんまり。

オフにしますか？番号。

理由：人がずさんなコードを書いて、アクセサーでメンバー変数を設定できなかったバグを3つ見つけました。すべてのバグを見つけるのは難しいことがわかりました。

これが将来のバージョンのJavaでデフォルトになることを期待しています。値渡し/参照によるものは、非常に多くの後輩プログラマーをつまずかせます。

もう1つ..私のメソッドはパラメーターの数が少ない傾向があるため、メソッド宣言の余分なテキストは問題になりません。

メソッドパラメータでfinalを使用しても、呼び出し側の引数に何が起こるかとは関係ありません。そのメソッド内で変更されていないものとしてマークすることのみを目的としています。私はより関数型のプログラミングスタイルを採用しようとしているので、その価値を理解しています。

個人的には、メソッドリストのfinalを使用しません。パラメーターリストが煩雑になるためです。Checkstyleのような方法でメソッドパラメータが変更されないようにすることをお勧めします。

ローカル変数については、可能であればいつでもfinalを使用します。個人プロジェクトのセットアップでは、Eclipseにそれを自動的に行わせます。

確かに、C / C ++ constのような強力なものが欲しいです。

Javaは引数のコピーを渡すので、妥当性finalはかなり限られていると感じています。習慣をつけるとC ++の時代から来たと思いますconst char const *。この種のものは、開発者が本質的にf ***のように愚かであり、彼が入力するすべての文字から本当に保護される必要があると信じさせてくれると思います。控えめに言っても、私が省略したとしても、私はほとんどバグを書きfinalません（自分のメソッドとクラスを誰かにオーバーライドさせたくない場合を除きます）。たぶん私は昔ながらの開発者だと思います。

パラメータリストで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;
}

悪魔の擁護者を演じて、これを行うことで何が間違っているのですか？

短い答え：finalほんの少しは役立ちますが...代わりにクライアント側で防御プログラミングを使用してください。

実際、の問題finalは、参照が変更されないことのみを強制し、呼び出し元に気付かれずに、参照されるオブジェクトメンバーを変更できるようにすることです。したがって、この点でのベストプラクティスは、呼び出し側での防御的プログラミングであり、悪質なAPIに悪用される恐れのあるオブジェクトの深く不変のインスタンスまたは深いコピーを作成します。

finalをパラメーター宣言に追加するもう1つの理由は、「抽出メソッド」リファクタリングの一部として名前を変更する必要がある変数を識別するのに役立つことです。大きなメソッドのリファクタリングを開始する前に各パラメータにfinalを追加すると、続行する前に対処する必要がある問題があるかどうかがすぐにわかります。

ただし、通常はリファクタリングの最後にそれらを不要なものとして削除します。

ミシェルの投稿をフォローアップしてください。私自身も、それを説明するための別の例を作りました。お役に立てれば幸いです。

public static void main(String[] args){
    MyParam myParam = thisIsWhy(new MyObj());
    myParam.setArgNewName();

    System.out.println(myParam.showObjName());
}

public static MyParam thisIsWhy(final MyObj obj){
    MyParam myParam = new MyParam() {
        @Override
        public void setArgNewName() {
            obj.name = "afterSet";
        }

        @Override
        public String showObjName(){
            return obj.name;
        }
    };

    return myParam;
}

public static class MyObj{
    String name = "beforeSet";
    public MyObj() {
    }
}

public abstract static class MyParam{
    public abstract void setArgNewName();
    public abstract String showObjName();
}

上記のコードから、thisIsWhy（）メソッドでは、実際には[引数MyObj obj]をMyParamの実際の参照に割り当てていません。代わりに、MyParam内のメソッドで[引数MyObj obj]を使用します。

しかし、我々は法の終了した後thisIsWhyを（） 、引数が（オブジェクト）このmyobjはまだ存在している必要がありますか？

mainでまだメソッドshowObjName（）を呼び出しており、 objに到達する必要があるので、そうであるように見えます。MyParamは、メソッドがすでに返されていても、メソッド引数を使用/到達します！

Javaが実際にこれを実現する方法は、コピーを生成することでもありますが、MyParamオブジェクト内の引数MyObj objの非表示の参照です（ただし、MyParamの正式なフィールドではないため、見えません）。

「showObjName」を呼び出すと、その参照を使用して対応する値が取得されます。

ただし、引数をfinalに設定しなかった場合は、新しいメモリ（オブジェクト）を引数MyObj objに再度割り当てることができます。

技術的にはまったく衝突はありません！これが許可されている場合、以下の状況になります。

1. これで、MyParamオブジェクトにある[ヒープ内のメモリA]を指す[MyObj obj]ポイントが非表示になりました。
2. また、thisIsWhyメソッドに[ヒープ内のメモリB]への引数ポイントである別の[MyObj obj]が追加されました。

衝突はありませんが、「混乱しています!!」それらはすべて"obj"である同じ "参照名"を使用しているためです。

これを回避するには、プログラマが「間違いやすい」コードを実行しないように、「最終」に設定します。