2

Genericsの学習を終えましたが、簡単ではありませんでした。しかし、私はそれを理解しました。これが私が理解したことです。私が間違っているところを訂正して、いくつかの質問に答えてほしい:)。 

public class LinkedList<T> {
//class definition
}

  • これは、LinkedList <>が、クラスのオブジェクトとインターフェイスを受け入れるクラスであることを意味します。

    • public class LinkedList<T extends Object> {
//class definition
}

  • これは、LinkedList <>が、Objectクラスを拡張するクラスのオブジェクトのみを受け入れるクラスであることを意味します。基本的に、すべてのクラス。rawタイプの場合、TはObjectに置き換えられます

    • public class LinkedList<T extends Object & java.lang.Serializable> {
//class definition
}

  • これは、LinkedList <>が、 Serializableインターフェイスを実装するすべてのクラスのオブジェクトを受け入れるクラスであることを意味します。ユーザー定義クラスのオブジェクトをリストに含める必要がある場合、ユーザー定義クラスはSerializableを実装する必要があります。

    • public class LinkedList<T> implements Iterable<T> {
//class definition
}

  • これは、LinkedList<>クラスをコレクションベースのforループで使用できることを意味します。iterator（）メソッドをオーバーロードする必要があり、Itarator<T>hasNext（）、next（）、およびremove（）を実装およびオーバーロード する内部クラスが必要です。

    • 質問1.これの意味を簡単 な
    言葉で、可能であれば例を挙げて説明してください 。2. writeObject（）メソッドを使用して、上記のLinkedList<>クラスをファイルに書き込みたい。だから私はそれを次のように宣言します
    BinaryTree<T extends Comparable<? super T>>

    public class LinkedList<T extends Object> implements Serializable {
     //methods and data members      
private class Node implements Serializable { //inner class
                  T object;
                  Node next;
           }
    }

    内部クラスもSerializableを実装する必要がありますか？

    4

    3 に答える 3

    2

    最初の4つのポイントについて：

    1. T（拡張するクラスを含む）のインスタンスを含むことになっているリストT。
    2. すべてのクラスが拡張されるため、実際には最初のものと同じですObject。
    3. Serializable（と同じclass LinkedList<T extends Serializable> { ... }）であるオブジェクトのみを含むことができるリスト
    4. の反復可能なリストなTので、そうです、拡張ループで使用できます。

    注目に値するのは、「指定されたタイプのオブジェクトのみを含むことができるリスト」と言うときは、「can」ではなく「should」と言う必要があります。オブジェクトを渡さない限りClass<?>、Java（ランタイム）は渡された値が実際に準拠しているかどうかをチェックせず、コンパイラーのみがチェックし、手動で変更された可能性のある表示された静的タイプにのみ基づいています（警告が発生します）。

    質問について：

    1. これは、そのスーパータイプと同じクラスまたはそのスーパータイプのいずれかのオブジェクトに対するオブジェクトBinaryTreeを含むを表します（これは、すべてのクラスの1つのスーパータイプであり、基本的に、拡張するすべてのクラスと、それが実装するすべてのインターフェイスです）。ComparableTObjectT
    2. を使用してオブジェクトをシリアル化する場合は、そのオブジェクトのwriteObjectすべての非一時的（つまり、他のデータに基づいて再構築できない）インスタンスフィールドSerializableも同様である必要があります。そうでない場合writeObjectは無視されます。Nodeコード抽出は、必要かどうかを判断するのに十分ではありませんSerializableが、おそらくList例の一般的な考え方を示す必要があります。
    于 2012-06-01T15:03:09.790 に答える
    1

    いくつかの説明を追加するには：

    T任意の参照型を表します。クラス、インターフェイス、配列の場合もあれば、パラメータ化された型の場合もあります。クラスとインターフェースなどの区別はありません。

    T extends ObjectTすべての参照型がのサブタイプであるためと同じですObject（はい、インターフェイスものサブタイプですObject）。extends Object一種の冗長です。

    T extends Object & SerializableTとの両方のサブタイプである必要がObjectありSerializableます。前に述べたように、すべてがのサブタイプでObjectあるため、今のところ、と同じであると見なすことができます（最初のケースでは消去が行われ、2番目のケースでは消去されるT extends Serializableため、わずかに異なります;ただし、する必要はありません。この時点でこれについて心配してください）。TObjectSerializable

    于 2012-06-01T18:39:21.700 に答える
    0

    Oracleガイドラインから：

    注-ローカルクラスや匿名クラスを含む内部クラス（つまり、静的メンバークラスではないネストされたクラス）のシリアル化は、いくつかの理由から強くお勧めしません。非静的コンテキストで宣言された内部クラスには、クラスインスタンスを囲む暗黙の非一時的な参照が含まれているため、そのような内部クラスインスタンスをシリアル化すると、関連する外部クラスインスタンスもシリアル化されます。内部クラスを実装するためにjavac（または他のJavaTMコンパイラ）によって生成される合成フィールドは実装に依存し、コンパイラによって異なる場合があります。このようなフィールドの違いにより、互換性が損なわれるだけでなく、デフォルトのserialVersionUID値が競合する可能性があります。ローカルおよび匿名の内部クラスに割り当てられた名前も実装に依存し、コンパイラ間で異なる場合があります。内部クラスはコンパイル時定数フィールド以外の静的メンバーを宣言できないため、serialPersistentFieldsメカニズムを使用してシリアル化可能なフィールドを指定することはできません。最後に、外部インスタンスに関連付けられた内部クラスには引数ゼロのコンストラクターがないため（このような内部クラスのコンストラクターは、包含インスタンスを付加パラメーターとして暗黙的に受け入れます）、Externalizableを実装できません。ただし、上記の問題はいずれも静的メンバークラスには当てはまりません。Externalizableを実装することはできません。ただし、上記の問題はいずれも静的メンバークラスには当てはまりません。Externalizableを実装することはできません。ただし、上記の問題はいずれも静的メンバークラスには当てはまりません。

    シリアル化可能なインターフェイス、クラスのシリアル化可能なフィールドの定義

    于 2012-06-01T15:04:28.340 に答える