抽象クラスが既にあるのに、なぜJava 8のインターフェイスにデフォルトおよび静的メソッドが追加されたのですか？

Java 8では、インターフェイスに実装メソッド、静的メソッド、いわゆる「デフォルト」メソッド（実装クラスがオーバーライドする必要はありません）を含めることができます。

私の（おそらく素朴な）見解では、このようなインターフェースに違反する必要はありませんでした。インターフェイスは常にあなたが満たさなければならない契約であり、これは非常にシンプルで純粋な概念です。今では、いくつかのものが混在しています。私の考えでは：

1. 静的メソッドはインターフェイスに属しません。これらはユーティリティクラスに属します。
2. 「デフォルト」メソッドはインターフェースでまったく許可されるべきではありません。この目的には常に抽象クラスを使用できます。

要するに：

Java 8より前：

• 抽象クラスと通常クラスを使用して、静的メソッドとデフォルトメソッドを提供できます。インターフェイスの役割は明確です。
• クラスを実装することにより、インターフェイス内のすべてのメソッドをオーバーライドする必要があります。
• すべての実装を変更せずにインターフェイスに新しいメソッドを追加することはできませんが、これは実際には良いことです。

Java 8以降：

• インターフェースと抽象クラス（多重継承を除く）には実質的に違いはありません。実際、インターフェイスを使用して通常のクラスをエミュレートできます。
• 実装をプログラミングするとき、プログラマはデフォルトのメソッドをオーバーライドするのを忘れることがあります。
• クラスが同じシグネチャを持つデフォルトメソッドを持つ2つ以上のインターフェイスを実装しようとすると、コンパイルエラーが発生します。
• インターフェイスにデフォルトのメソッドを追加することにより、実装するすべてのクラスがこの動作を自動的に継承します。これらのクラスの一部は、その新しい機能を念頭に置いて設計されていない可能性があり、これにより問題が発生する可能性があります。たとえば、誰かが新しいデフォルトのメソッドdefault void foo()をinterface Ixに追加すると、同じシグネチャを持つプライベートメソッドをCx実装Ixしているクラスfooはコンパイルされません。

このような大きな変更の主な理由は何ですか？また、追加された新しいメリット（ある場合）は何ですか？

デフォルトメソッドの良い動機付けの例は、Java標準ライブラリにあります。

list.sort(ordering);

の代わりに

Collections.sort(list, ordering);

そうでなければ、複数の同一の実装がなければ、それを行うことができなかったと思いますList.sort。

正しい答えは、実際にはJava Documentationに記載されています。

[d] efaultメソッドを使用すると、ライブラリのインターフェイスに新しい機能を追加し、それらのインターフェイスの古いバージョン用に記述されたコードとのバイナリ互換性を確保できます。

インターフェースは、いったん公開されると進化することが不可能になる傾向があったため、これはJavaの長年の痛みの原因でした。（ドキュメントの内容は、コメントでリンクした論文に関連しています：仮想拡張メソッドによるインターフェースの進化。）さらに、新機能（ラムダや新しいストリームAPIなど）の迅速な採用は、既存のコレクションインターフェイスと既定の実装の提供。バイナリ互換性を破るか、新しいAPIを導入するということは、Java 8の最も重要な機能が一般的に使用されるまでに数年かかることを意味します。

インターフェイスで静的メソッドを許可する理由は、ドキュメントで再び明らかになりました。[t] hisを使用すると、ライブラリでヘルパーメソッドを簡単に整理できます。インターフェースに固有の静的メソッドを、別個のクラスではなく同じインターフェースに保持できます。言い換えれば、java.util.Collections現在の（最終的に）静的ユーティリティクラスは、一般的に（もちろん常にではない）アンチパターンと考えることができます。私の推測では、この動作のサポートを追加することは、仮想拡張メソッドが実装された後は簡単なことでした。さもなければ、おそらく実行されなかったでしょう。

同様の注意として、これらの新機能がどのように役立つかという例は、最近私を悩ませる1つのクラスを考慮することですjava.util.UUID。UUIDタイプ 1、2、または5のサポートは実際には提供されず、そのために容易に変更することはできません。また、オーバーライドできない事前定義済みのランダムジェネレーターもあります。サポートされていないUUIDタイプのコードを実装するには、インターフェイスではなくサードパーティAPIに直接依存するか、変換コードのメンテナンスとそれに伴う追加のガベージコレクションのコストが必要です。静的メソッドを使用すると、UUID代わりにインターフェイスとして定義でき、欠落している部分の実際のサードパーティ実装が可能になります。（UUID元々インターフェースとして定義されていた場合、おそらくある種の不格好なものがあるでしょうUuidUtil 多くのJavaのコアAPIは、インターフェイスに基づいていないために低下しますが、Java 8では、この悪い動作の言い訳の数はありがたいことに減少しました。

[t]ここでインターフェイスと抽象クラスの違いは事実上ない、と言うのは正しくありません。抽象クラスは状態を持つことができる（つまり、フィールドを宣言する）が、インターフェイスはできないからです。したがって、多重継承やミックスインスタイルの継承と同等ではありません。適切なミックスイン（Groovy 2.3の特性など）は状態にアクセスできます。（Groovyは静的拡張メソッドもサポートしています。）

私の意見では、Dovalの例に従うのも良い考えではありません。インターフェイスはコントラクトを定義することになっていますが、コントラクトを強制することは想定されていません。（とにかくJavaではありません。）実装の適切な検証は、テストスイートまたは他のツールの責任です。コントラクトの定義はアノテーションを使用して行うことができ、OValは良い例ですが、インターフェイスで定義された制約をサポートするかどうかはわかりません。そのようなシステムは、たとえ現在存在していなくても実現可能です。（戦略にはjavac、注釈プロセッサによるコンパイル時のカスタマイズが含まれますAPIとランタイムバイトコードの生成。理想的には、テストスイートを使用して、コンパイル時に、最悪の場合にコントラクトが実施されますが、ランタイムの実施は眉をひそめているというのが私の理解です。Javaでのコントラクトプログラミングを支援する別の興味深いツールは、Checker Frameworkです。

継承できるクラスは1つだけだからです。実装が複雑で抽象基本クラスが必要な2つのインターフェイスがある場合、これら2つのインターフェイスは実際には相互に排他的です。

別の方法は、これらの抽象基本クラスを静的メソッドのコレクションに変換し、すべてのフィールドを引数に変換することです。これにより、インターフェイスの実装者は静的メソッドを呼び出して機能を取得できますが、すでに冗長すぎる言語ではひどく多くの定型文です。

インターフェースで実装を提供できることがなぜ役に立つのかという動機付けの例として、次のStackインターフェースを検討してください。

public interface Stack<T> {
    boolean isEmpty();

    T pop() throws EmptyException;
 }

誰かがインターフェースを実装したときにpop、スタックが空の場合に例外をスローすることを保証する方法はありません。このルールは、コントラクトを実行するメソッドと実際のポップを実行するメソッドのpop2つのメソッドに分けることで実行できます。public finalprotected abstract

public abstract class Stack<T> {
    public abstract boolean isEmpty();

    protected abstract T pop_implementation();

    public final T pop() throws EmptyException {
        if (isEmpty()) {
            throw new EmptyException();
        else {
            return pop_implementation();
        }
    }
 }

すべての実装がコントラクトを尊重することを保証するだけでなく、スタックが空かどうかをチェックして例外をスローする必要がないようにしました。インターフェースを抽象クラスに変更しなければならなかったという事実を除いて、それは大きな勝利です！単一の継承を持つ言語では、柔軟性が大きく失われます。これにより、インターフェイスが相互排他的になります。インターフェイスメソッド自体にのみ依存する実装を提供できると、問題は解決します。

インターフェイスにメソッドを追加するJava 8のアプローチが最終メソッドまたは保護された抽象メソッドの追加を許可するかどうかはわかりませんが、D言語がそれを許可し、Design by Contractのネイティブサポートを提供することを知っています。popfinalであるため、この手法には危険はありません。したがって、実装クラスはそれをオーバーライドできません。

オーバーライド可能なメソッドのデフォルトの実装に関しては、Java APIに追加されたデフォルトの実装はすべて、追加されたインターフェースのコントラクトのみに依存するため、インターフェースを正しく実装するクラスもデフォルトの実装で正しく動作します。

また、

インターフェースと抽象クラス（多重継承を除く）には実質的に違いはありません。実際、インターフェイスを使用して通常のクラスをエミュレートできます。

インターフェイスではフィールドを宣言できないため、これはまったく当てはまりません。インターフェイスに記述するメソッドは、実装の詳細に依存できません。

インターフェイスで静的メソッドを優先する例として、Java APIのコレクションのようなユーティリティクラスを検討してください。これらの静的メソッドは、それぞれのインターフェイスで宣言できないため、そのクラスのみが存在します。インターフェースでCollections.unmodifiableList宣言することもできたListでしょうし、見つけやすかったでしょう。

おそらく、その目的は、依存関係を介して静的情報または機能を注入する必要性を置き換えることにより、ミックスインクラスを作成する機能を提供することでした。

このアイデアは、C＃で拡張メソッドを使用して、実装された機能をインターフェイスに追加する方法に関連しているようです。

defaultメソッドに見られる2つの主な目的（いくつかのユースケースは両方の目的に役立ちます）：

1. 構文シュガー。ユーティリティクラスはその目的に役立ちますが、インスタンスメソッドの方が優れています。
2. 既存のインターフェースの拡張。実装は一般的ですが、時には非効率的です。

それが第2の目的にすぎない場合、のようなまったく新しいインターフェースには表示されませんPredicate。@FunctionalInterfaceラムダが実装できるように、すべての注釈付きインターフェイスには抽象メソッドが1つだけ必要です。追加しましたdefaultような方法にはand、or、negateちょうどユーティリティであり、あなたはそれらを上書きすることになっていません。ただし、静的メソッドのほうが優れている場合があります。

既存のインターフェースの拡張に関しては、それでも、いくつかの新しいメソッドは単なる構文糖です。方法Collectionのようにstream、forEach、removeIf-基本的に、それはあなたがオーバーライドする必要はありません。ただユーティリティです。そして、のようなメソッドがありますspliterator。デフォルトの実装は最適ではありませんが、少なくともコードはコンパイルされます。インターフェイスが既に公開され、広く使用されている場合のみ、これに頼ってください。

staticメソッドについては、他の人がそれを非常によくカバーしていると思います。これにより、インターフェイスを独自のユーティリティクラスにすることができます。おそらくCollections、Javaの将来を取り除くことができるでしょうか？Set.empty()揺れるだろう。