私は 100 ～ 150 のクラスと...パフ..多くのメソッドを持つプロジェクトを仕上げています。開発にあたっては、最初から「可能な場合はモディファイヤ 'final' を使用する」セーブ アクションを使用しました。しかし、これにより、メソッド (およびアシスタントを使用する代わりに手動で作成したクラス) が、必要な final/abstract キーワードなしで使用できるようになります。実際、すべてのクラスとメソッドの宣言を手動で完了する必要はありません。私は、最も制限的な方法で「私のためにそれを行う」ようにEclipseに指示する方法があると確信しています（つまり、クラスがインスタンス化されていない場合は抽象として設定し、そうでない場合は拡張されていない場合は最終として設定し、それ以外の場合は何もしません、および同様のもの-抽象部分なし、明らかに-メソッド用）。
私は正しいですか？もしそうなら、その道はどちらですか？
ヒューリスティックを強制するのは問題があるかもしれません。これが、Eclipse がそれらを実装しない理由である可能性があります。
コード内で拡張されていないすべてのクラスをfinal- に設定する - IDE は、それらが他の場所で拡張されることを意図しているかどうかをどのように知ることができますか? final本当に拡張を禁止する場合にのみ作成してください。
同じことが当てはまりabstractます - IDE があなたがフレームワークを書いているのか、初期化がまったくないドメインモデルを書いているのかを知る方法は.jarありません。エンティティabstractを自動的に作成すると、後で足を撃たれる可能性があります。
これは変数の場合はめったにないため、このヒューリスティック Eclipse で実行できます。
編集私は自分の推論について少し詳しく説明する必要があると思います。
変数はほとんどローカライズされているため、修飾子を追加してfinalも問題はありません。変数は、制御下のコードのスコープ内に存在します。サードパーティのコードに表示され、メソッドを呼び出さずに変更できる変更可能な変数はめったにありません。
変数のfinal修飾子が過剰な場合、その影響はコードに限定され、おそらくすぐに気付くでしょう。したがって、最悪の場合、ファイルを開いて修飾子を削除する必要があります。
クラスの場合は異なります。クラスの多くは公開されているため、サードパーティのコードにアクセスできます。コード内でインスタンス化されていないすべてのクラスを として宣言するとabstract、他のすべての人がインスタンス化することを効果的に禁止できます。したがって、ここでの最悪のケースは、他の誰かがあなたのコードを使用できなくなることです。それが私が自動化しない理由です - ほとんどの場合、サードパーティのコードで定義したクラスをインスタンス化できるようにしたいでしょう。
ただし、いつクラスを作成するかについてはヒューリスティックがありfinalます。つまり、クラスに静的メソッドしかない場合です。PMD や Checkstyle などの一部のツールはそれを認識しており、それについて教えてくれます。このオプションは実際には Eclipse にうまく適合しますが、残念ながら実装されていません。
デフォルトごとにクラスを作成することについてfinalは、andersoj や他の多くの人が「継承のための設計またはそれを禁止する」という原則に従っていますが、それは Joshua Bloch が彼の「Effective Java」の本で紹介したと思います。他の人は、デフォルトですべてのクラスを「封印」することは、開閉の原則に違反すると主張します。私は後者の傾向があります。
最終クラスの場合、クラスを最終としてマークするだけでよく、各メソッドをマークする必要はありません...おそらくそれは少し役に立ちます。kostjaの答えとは対照的に、デフォルトでクラスをfinalとしてマークし、拡張用に明示的に設計した場合にのみfinalを省略します。特別なことをしているのでない限り、これはとにかく例外的なケースであるはずです（「拡張よりも構成を好む」）。