私は今日、Eclipse の「プル・インターフェース」リファクタリング機能を使用して、既存のクラスに基づいたインターフェースを作成しました。このダイアログ ボックスでは、新しいインターフェイスのすべての新しいメソッドを「抽象」メソッドとして作成することができました。
その利点は何でしょうか。
インターフェースメソッドを抽象として宣言できるという事実は、特に推奨されていない言語の不要で無害な機能だと思いました。
Eclipse がそのようなスタイルをサポートする理由、または誰かが自発的にサポートすることを選択する理由は何ですか?
明確化: インターフェイス メソッドが抽象である理由を尋ねているわけではありません。それは明らかです。それらがインターフェースにある場合、とにかく抽象的であるため、それらを抽象としてマークすることを明示的に選択する理由を尋ねています。
Java 言語仕様によると、 interfacesのabstractキーワードは廃止されており、使用できなくなりました。(セクション 9.1.1.1)
abstractとはいえ、下位互換性に対する Java の傾向を考慮すると、キーワードが存在するかどうかで違いが生じることはないと思います。
Java SE 7 JLS (Java 言語仕様)から: 「インターフェイスで宣言されたメソッドの public および/または abstract 修飾子を重複して指定することは許可されていますが、スタイルの問題としてお勧めできません。」
Java SE 5.0の場合: 「Java プラットフォームの古いバージョンとの互換性のために、インターフェイスで宣言されたメソッドの抽象修飾子を重複して指定することは、スタイルの問題として許可されていますが推奨されません。」
Eclipse の「その利点」(インターフェース メソッド宣言に抽象を追加する) は、jdk1.3 の jdt Eclipse コンパイラとの古い互換性の問題です。
1.4 以降、jdk ライブラリにはデフォルトの抽象メソッド (インターフェースを実装する抽象クラス) が含まれなくなりました。
これは、Eclipse 1.3 コンパイラーの診断をごまかしています。これは、それらの実装がそれらの存在に依存しているためです。
Javac 1.3 は、1.4 ライブラリに対して実行することを完全に拒否することに注意してください (-bootclasspath オプションを使用)。
Eclipse コンパイラーは 1.4 準拠レベル (「参考文献」を参照) である可能性が高いためWorkbench>Preferences>Java>Compiler>JDK Compliance、または 1.3 準拠モードを使用する場合は少なくとも 1.3 クラス・ライブラリーを使用するため、現在のほとんどの Eclipse プロジェクトでは「抽象」の存在は必要ありません。
JLS によると、インターフェイスのメソッドはデフォルトで抽象的であるため、キーワードは冗長です。これを知っているので、「プレゼンテーションの混乱を避ける」ためにそれを使用することは決してありません。