ワイルドカード ジェネリック型の複雑さ
Java ワイルドカード ジェネリックは、特定の具象型にコミットせずに型を表現する方法を提供します。この柔軟性は強力ですが、予期しない動作を引き起こす可能性もあります。
親インターフェイスの不明なサブタイプの Java リストが定義されている次の例を考えてみましょう。
List<? extends Parent> list = ...;
ただし、Java の型システムでは、このリストに親インスタンスを追加することはできません:
Parent p = factory.get(); // returns concrete implementation list.set(0, p); // compilation error
この明らかな矛盾は、次の概念から生じます。タイプセーフティ。リストへの親インスタンスの追加を許可すると、ワイルドカード ジェネリック型の整合性が損なわれます。その理由は次のとおりです:
この追加が許可された場合を想像してください。 Parent の具体的なサブタイプである Child インスタンスのリストがあるとします。
List<Child> childList = new ArrayList<Child>(); childList.add(new Child());
この childList をワイルドカードのジェネリック型を使用してリストに割り当てると、リストがあるように見えます。親インスタンスの数:
List<? extends Parent> parentList = childList;
ただし、これに親インスタンスを追加できる可能性があります。 parentList:
parentList.set(0, new Parent());
これは致命的な型安全性違反を引き起こす可能性があります。後で childList からインデックス 0 の項目を取得するとき、それは Child インスタンスであると予想されますが、実際には Parent インスタンスであり、予期しない動作が発生します。
この型安全性違反を防ぐには、次のようにします。 Java では、スーパータイプのインスタンスを取得できる場合でも、リストに追加できるのはワイルドカード ジェネリック タイプ自体のインスタンスのみであるというルールが適用されます。この制限により、型パラメータの整合性が保証され、潜在的なバグが防止されます。
以上が「親」インスタンスを「リスト」に追加できないのはなぜですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。