Java抽象インターフェース

例を考えてみましょう（Javaでコンパイルされます）

public abstract interface Interface {
    public void interfacing();
    public abstract boolean interfacing(boolean really);
}

インターフェイスを抽象的に「宣言」する必要があるのはなぜですか？抽象インターフェースに適用される他のルールはありますか？

最後に：abstract時代遅れの場合、なぜJavaに含まれているのですか？抽象インターフェースの歴史はありますか？

インターフェイスを抽象的に「宣言」する必要があるのはなぜですか？

そうではありません。

public abstract interface Interface {
       \___.__/
           |
           '----> Neither this...

    public void interfacing();
    public abstract boolean interfacing(boolean really);
           \___.__/
               |
               '----> nor this, are necessary.
}

インターフェースとそのメソッドは暗黙的でabstractあり、その修飾子を追加しても違いはありません。

抽象インターフェースに適用される他のルールはありますか？

いいえ、同じルールが適用されます。このメソッドは、（具体的な）実装クラスによって実装する必要があります。

抽象が古くなっているのに、なぜJavaに含まれているのですか？抽象インターフェースの歴史はありますか？

興味深い質問です。JLS の最初の版を掘り起こしましたが、そこにも「この修飾子は廃止されており、新しいJavaプログラムでは使用しないでください」と書かれています。

さて、さらに掘り下げて ...壊れたリンクを数多く見つけた後、私はなんとかオリジナルのOak 0.2 仕様（または「マニュアル」）のコピーを見つけました。私が言わなければならないかなり興味深い読み、そして合計で38ページだけ！:-)

セクション5の「インターフェース」で、次の例を示します。

public interface Storing {
    void freezeDry(Stream s) = 0;
    void reconstitute(Stream s) = 0;
}

そしてマージンにはそれが言う

将来的には、インターフェイスでのメソッドの宣言の「= 0」部分がなくなる可能性があります。

キーワードに=0置き換えられたと仮定すると、ある時点でabstractそれabstractがインターフェイスメソッドに必須であったと思います！

関連記事：Java：抽象インターフェースと抽象インターフェースメソッド

publicインターフェースメソッドと同様に、これは必須ではなく、オプションです。

これに関するJLSを参照してください。

http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html

9.1.1.1抽象インターフェースすべてのインターフェースは暗黙的に抽象です。この修飾子は廃止されており、新しいプログラムでは使用しないでください。

そして

9.4抽象メソッド宣言

[...]

古いバージョンのJavaプラットフォームとの互換性のために、スタイルの問題として、インターフェイスで宣言されたメソッドの抽象修飾子を重複して指定することは許可されていますが、お勧めできません。

インターフェースメソッドのパブリック修飾子を重複して指定することは許可されていますが、スタイルの問題としては強くお勧めできません。

インターフェースの抽象を宣言する必要はありません。

これらすべてのメソッドをpublic（インターフェースがpublicの場合はすでに宣言されている）またはabstract（すでにインターフェースに含まれている）と宣言するのと同じように冗長です。

しかし、誰もあなたを止めません。

あなたが明示的に述べることができるが、する必要のない他のもの：

• コンストラクタの最初の行でsuper（）を呼び出す
• extends Object
• 継承されたインターフェースを実装する

抽象インターフェースに適用される他のルールはありますか？

インターフェースはすでに「抽象的」です。そのキーワードを再度適用しても、まったく違いはありません。

春にそれは非学術的な意味を持っていることに注意してください。抽象インターフェースは、それをに使用しないように開発者に警告するものです@Autowired。春/日食@Autowiredがこの属性を見て、その使用法について警告/失敗するます。

実際の例：@Repositoryに対する@Transnationalの下の@Serviceプロキシは、同じ基本的なメソッドを使用する必要がありますが、により、この抽象インターフェースを拡張する異なるインターフェースを使用する必要があります@Autowired。（これをXXXSpecインターフェースと呼びます）

すべてのインターフェースは暗黙的に抽象的です。
この修飾子は廃止されており、新しいプログラムでは使用しないでください。

[Java言語仕様-9.1.1.1 abstractインターフェース]

また、インターフェイスメンバーメソッドは暗黙的に使用されることにも注意してくださいpublic abstract。
[Java言語仕様-9.2インターフェースメンバー]

なぜこれらの修飾子は暗黙的なのですか？ここで役立つ他の修飾子（ ' no modifier ' -modifierも含めない）はないため、明示的に入力する必要はありません。

必要ありません。それは言語の癖です。

インターフェースのすべてのメソッドは抽象であるため、インターフェースはデフォルトで抽象であるため、これは必要ありません。

少なくとも理論的には、抽象インターフェースは誰もが言っているように冗長ではありません。

インターフェイスは、クラスと同じように拡張できます。アプリケーションのインターフェース階層を設計する場合、「ベース」インターフェースを使用している可能性があります。他のインターフェースを拡張しますが、それ自体はオブジェクトとして必要ありません。

例：

public abstract interface MyBaseInterface {
    public String getName();
}

public interface MyBoat extends MyBaseInterface {
    public String getMastSize();
}

public interface MyDog extends MyBaseInterface {
    public long tinsOfFoodPerDay();
}

クラスにMyBaseInterfaceを実装するのではなく、他の2つのMMyDogとMyBoatだけを実装する必要がありますが、両方のインターフェースがMyBaseInterfaceインターフェースを共有するため、「name」プロパティがあります。

ちょっとアカデミックなことは知っていますが、面白いと思う人もいると思いました。:-)

この場合、実際には単なるマーカーであり、独自に実装するように設計されていないインターフェースの実装者に信号を送ります。コンパイラー（少なくとも、私が試したsun / ora 1.6）が抽象インターフェースを実装するクラスをコンパイルすることを指摘しておきます。

まあ「抽象インターフェース」は字句の構成要素です：http : //en.wikipedia.org/wiki/Lexical_analysis。

コンパイラーで必要ですが、と書くこともできますinterface。

言語の語彙構成に深く入りすぎないようにしてください。コンパイルプロセス中の特別なケースと呼ばれるコンパイルのあいまいさを解決するため、または下位互換性のために、コアの語彙構成に焦点を当ててみてください。

`インターフェイスの本質は、実装が異なる可能性があるいくつかの抽象的な概念（アイデア/思考/高次の思考など）を取り込むことです...つまり、複数の実装が存在する可能性があります。

インターフェースは、キャプチャまたは表現しているオブジェクトの機能を表す純粋な抽象データ型です。

特徴は空間または時間で表すことができます。それらがスペース（メモリストレージ）で表される場合、具体的なクラスがフィールドとそのフィールドまたは時間で動作するメソッド/メソッドを実装することを意味します。つまり、機能を実装するタスクは純粋に計算的です（より多くのCPUクロックが必要）。処理のために）機能実装の空間と時間の間のトレードオフがあります。

具象クラスがすべての機能を実装していない場合は、思考、アイデア、または抽象性の実装があるため、再び抽象化されますが、完全ではないため、abstractクラスで指定します。

具象クラスは、クラスXYZをキャプチャしようとしている抽象性を完全にキャプチャするクラス/クラスのセットになります。

したがって、パターンは

Interface--->Abstract class/Abstract classes(depends)-->Concrete class