初めて技術的な乾物と業界情報を入手してください！
昨日は忙しすぎて、とても遅く帰ってきました。多くの人が私を個人的に信頼してくれて、寝る前に一人ずつ答えてくれました。今日はお急ぎですので、ずっと前に書いた記事をみんなにお勧めします！
最近、Githubで人気のあるプロジェクトを見て、スターがvueを超えました。githubで星のランキングを見たかったのですが、読んだ後、突然、stackoverflowのランキングを見られるかと思いました。いくつかの翻訳も素晴らしいです！
stackoverflowを開くと、突然非常に奇妙な質問が表示されました。JavaのCollectionクラスが抽象クラスを継承するだけでなく、抽象クラスのインターフェイスも実装するのはなぜですか？
Javaの多くのCollectionクラスが抽象クラスを拡張し、インターフェイスも実装するのはなぜですか？
これは非常に良い質問であり、私が注意を払ったり考えたりしたことはありません。
一般的な翻訳をしますが、なぜこれをしたいのですか？
実際、Javaには、このような魔法の操作を行うコレクションがたくさんあります。例：HashSetはAbstractSetを継承してSetを実装しますが、AbstractSetはSetを実装しています。HashMapはAbstractMapを拡張し、AbstractMapはMapを実装します。
なぜあなたはこれをしたいのですか？上記の説明によると、最も重要な理由の1つは仕様です。対応する抽象クラスが実装されていない場合、影響はありませんが、対応する抽象クラスを実現することで、特定のクラスの完全な階層を経由せずにコードを理解することができます。
第二に、違いは反射で観察することができます。たとえば、次のコード：
実行後、次の結果を出力します。
上記の結果から、Listは実際にはCollectionインターフェイスを拡張しているが、Collectionインターフェイスは印刷されていないことがわかります。つまり、上記の出力には、スーパークラスによって実装されたインターフェイスは含まれていません。また、含まれているインターフェイスとしてスーパーインターフェイスのインターフェイスも含まれていません。たとえば、IterableとCollectionは、ArrayListが暗黙的に実装している場合でも、上記から省略されています。それらを見つけるには、クラス階層を再帰的に繰り返す必要があります。
幸い、この違いはinstanceofには影響しません。たとえば、IterableおよびIterable.class.isAssignableFrom（ArrayList.class）の新しいArrayList <>（）インスタンスはtrueになります。
JDKでのこれらのコレクションの実際の設計と実装である「読みやすさ」も非常に重要な部分です。