LinkedHashMap の JDK ソース コードを見ると、このクラスが次のように宣言されていることに気付きました。
public class LinkedHashMap<K,V>
extends HashMap<K,V>
implements Map<K,V>
{...
なぜ冗長な " implements Map<K,V>
" (HashMap
既に実装されているためMap
) ? これがタイプミスだとは思えない…
ありがとう。
LinkedHashMap の JDK ソース コードを見ると、このクラスが次のように宣言されていることに気付きました。
public class LinkedHashMap<K,V>
extends HashMap<K,V>
implements Map<K,V>
{...
なぜ冗長な " implements Map<K,V>
" (HashMap
既に実装されているためMap
) ? これがタイプミスだとは思えない…
ありがとう。
言い方だと思います
HashMap が (現在または将来) 実装するインターフェイスに関係なく、このクラスは Map インターフェイスを実装する必要があります。
HashMap の責任者が Map インターフェースを実装すべきではないと判断した場合、コンパイラは LinkedHashMap の管理者に、意図したとおりに Map インターフェースを実装していないことを警告します。
もちろん、この特定のケースではばかげていますが (HashMap は明らかに常に Map になります)、同様の状況がそのような慣習から恩恵を受ける可能性があります (そして、その慣習を生み出しました)。
それは古代のコードです。JDK 1.1.6前後のある時点まで、Javadocは継承されたインターフェースを表示していなかったため、Javadocを正しく機能させるには、派生クラスでそれらを繰り返す必要がありました。これらはJDK1.2で導入されましたが、1.1.xのアドオンとしてそれよりかなり前に利用可能でした。
スタイル/コード規則のようです: LinkedHashSet には同様の署名があります。インターフェースの使用法を強調するためだけかもしれません。C++ と比較すると、仮想関数が既に暗黙的に virtual であっても、すべての仮想関数で "virtual" を記述することをお勧めします。
これにより意図が明確になるため、これが特定の動作を伴うMap実装であることが明らかです。これは、HashMapを拡張することによって偶然に作成され、HashMapの代わりに一部の場所で使用できるようになります。 。
コーダー側のエラーである可能性があります。
また、インターフェイスの使用を明示的にしたいと考えていた可能性もあります。これを 2 回宣言しても、余分なキー ストローク以外に害はないので、問題はありません。
私の推測では、 LinkedHashMap が Map インターフェースで宣言されたメソッドのカスタム実装を提供できるようにすることです。この方法では、HashMap からすべての実装を継承することはありません。