ICollection インターフェイス
定義
重要
一部の情報は、リリース前に大きく変更される可能性があるプレリリースされた製品に関するものです。 Microsoft は、ここに記載されている情報について、明示または黙示を問わず、一切保証しません。
コレクション階層内のルート インターフェイス。
[Android.Runtime.Register("java/util/Collection", "", "Java.Util.ICollectionInvoker")]
[Java.Interop.JavaTypeParameters(new System.String[] { "E" })]
public interface ICollection : IDisposable, Java.Interop.IJavaPeerable, Java.Lang.IIterable[<Android.Runtime.Register("java/util/Collection", "", "Java.Util.ICollectionInvoker")>]
[<Java.Interop.JavaTypeParameters(new System.String[] { "E" })>]
type ICollection = interface
interface IIterable
interface IJavaObject
interface IDisposable
interface IJavaPeerable- 派生
- 属性
- 実装
注釈
コレクション階層内のルート インターフェイス。 コレクションは、その 要素と呼ばれるオブジェクトのグループを表します。 重複する要素を許可するコレクションもあれば、許可しないコレクションもあります。 順序付けされていないものもあれば、順序付けされていないものがあります。 JDK では、このインターフェイスの直接の実装は提供されません。これは、 や ListなどのSetより具体的なサブインターフェイスの実装を提供します。 このインターフェイスは、通常、コレクションを渡し、最大限の一般化が必要な場合にそれらを操作するために使用されます。
バッグ または マルチセット (重複する要素を含む可能性がある順序なしのコレクション) では、このインターフェイスを直接実装する必要があります。
すべての汎用 Collection 実装クラス (通常はサブインターフェイスのいずれかを介して間接的に実装 Collection する) には、空のコレクションを作成する void (引数なし) コンストラクターと、引数と同じ要素を持つ新しいコレクションを作成する型 Collectionの 1 つの引数を持つコンストラクターという 2 つの "標準" コンストラクターが用意されている必要があります。 実際には、後者のコンストラクターを使用すると、ユーザーは任意のコレクションをコピーし、目的の実装型の同等のコレクションを生成できます。 (インターフェイスにコンストラクターを含めることはできません) この規則を適用する方法はありませんが、Java プラットフォーム ライブラリのすべての汎用 Collection 実装が準拠しています。
特定のメソッドは 省略可能として指定されます。 コレクションの実装で特定の操作が実装されていない場合は、対応する メソッドを定義して をスロー UnsupportedOperationExceptionする必要があります。 このようなメソッドは、コレクション インターフェイスのメソッド仕様で "省略可能な操作" とマークされます。
"optional-restrictions">一部のコレクション実装には、含まれる要素に制限があります。 たとえば、null 要素を禁止する実装もあれば、要素の型に制限がある実装もあります。 無効な要素を追加しようとすると、チェックされていない例外 (通常 NullPointerException は または ClassCastException) がスローされます。 不適格な要素の存在を照会しようとすると、例外がスローされるか、単に false が返される可能性があります。一部の実装では以前の動作が示され、一部は後者を示します。 より一般的には、対象外の要素に対して操作を試みると、その完了によってコレクションに不適格な要素が挿入されない場合、実装のオプションで例外がスローされるか、成功する可能性があります。 このような例外は、このインターフェイスの仕様では "省略可能" としてマークされます。
独自の同期ポリシーを決定するには、各コレクションが必要です。 実装によるより強力な保証がない場合、未定義の動作は、別のスレッドによって変更されているコレクション上の任意のメソッドの呼び出しによって発生する可能性があります。これには、直接呼び出し、呼び出しを実行する可能性があるメソッドにコレクションを渡すこと、および既存の反復子を使用してコレクションを調べることが含まれます。
Collections Framework インターフェイスの多くのメソッドは、 メソッドの Object#equals(Object) equals 観点から定義されています。 たとえば、 メソッドの仕様#contains(Object) contains(Object o)では、"このコレクションに のような要素が少なくとも 1 つe(o==null ? e==null : o.equals(e))含まれている場合にのみ、 が返trueされます。 この仕様は、null 以外の引数oo.equals(e)を指定して をCollection.contains呼び出すと、要素 eに対して が呼び出されることを意味するものではありません。 実装では、2 つの要素のハッシュ コードを equals 最初に比較するなどして、呼び出しを回避する最適化を自由に実装できます。 (この仕様では Object#hashCode() 、ハッシュ コードが等しくない 2 つのオブジェクトを等しくすることはできません。より一般的には、さまざまな Collections Framework インターフェイスの実装は、実装者が適切と判断した場合に限り、基になる Object メソッドの指定された動作を自由に利用できます。
コレクションの再帰的走査を実行する一部のコレクション操作は、コレクション自体が直接または間接的に含まれる自己参照インスタンスの例外で失敗することがあります。 これには、、、clone()equals()hashCode()および toString() メソッドが含まれます。 実装では、必要に応じて自己参照シナリオを処理できますが、最新の実装では処理されません。
<h2>"view">View Collections</h2>
ほとんどのコレクションは、格納されている要素のストレージを管理します。 これに対し、 ビュー コレクション 自体は要素を格納するのではなく、実際の要素を格納するためにバッキング コレクションに依存します。 ビュー コレクション自体によって処理されない操作は、バッキング コレクションに委任されます。 ビュー コレクションの例としては、 などのCollections#checkedCollection Collections.checkedCollectionCollections#synchronizedCollection Collections.synchronizedCollectionCollections#unmodifiableCollection Collections.unmodifiableCollectionメソッドによって返されるラッパー コレクションがあります。 ビュー コレクションの他の例には、または Map#entrySet Map.entrySetでList#subList List.subListNavigableSet#subSet NavigableSet.subSet提供されるなど、同じ要素の異なる表現を提供するコレクションが含まれます。 バッキング コレクションに加えられた変更は、ビュー コレクションに表示されます。 それに対応して、ビュー コレクションに加えられた変更は mdash &。変更が mdash &許可されている場合。は、バッキング コレクションに書き込まれます。 これらは技術的にはコレクションではありませんが、 のIteratorListIteratorインスタンスを使用してバッキング コレクションに変更を書き込むこともできます。場合によっては、バッキング コレクションの変更は反復中に Iterator に表示されます。
<h2>"unmodifiable">Unmodifiable Collections</h2>
このインターフェイスの特定のメソッドは"破壊的" と見なされ、動作するコレクション内に含まれるオブジェクトのグループを変更するという点で"ミューテーター" メソッドと呼ばれます。 このコレクションの実装で操作がサポートされていない場合は、 をスロー UnsupportedOperationException するように指定できます。 このようなメソッドは、呼び出しがコレクションに影響を与えない場合は、 を UnsupportedOperationException スローする必要があります (ただし、必須ではありません)。 たとえば、操作をサポートしていないコレクションがあると #add add します。 このコレクションでメソッドが #addAll addAll 呼び出され、引数として空のコレクションが指定された場合はどうなりますか? 0 要素を追加しても効果がないため、このコレクションでは例外をスローせず、何も行わないだけで済みます。 ただし、特定のケースでのみをスローするとプログラミング エラーが発生する可能性があるため、このようなケースでは例外を無条件にスローすることをお勧めします。
変更できないコレクションはコレクションであり、そのすべてのミューテーター メソッド (上記で定義) が をスローUnsupportedOperationExceptionするように指定されています。 したがって、このようなコレクションは、その上のメソッドを呼び出すことによって変更することはできません。 コレクションを適切に変更できないようにするには、そのコレクションから派生したビュー コレクションも変更不可能である必要があります。 たとえば、List が変更できない場合、 によって List#subList List.subList 返されるリストも変更できません。
変更できないコレクションは、必ずしも不変であるとは限りません。 含まれている要素が変更可能な場合は、変更できない可能性がある場合でも、コレクション全体が明らかに変更可能です。 たとえば、変更可能な要素を含む 2 つの変更不可能なリストを考えてみましょう。 両方のリストが変更できない場合でも、要素が変更されている場合、呼び出しの結果は次の呼び list1.equals(list2) 出しとは異なる場合があります。 ただし、変更できないコレクションに変更できない要素がすべて含まれている場合は、実質的に不変と見なすことができます。
<h2>"unmodview">Unmodifiable View Collections</h2>
変更できないビュー コレクションは、変更不可能なコレクションであり、バッキング コレクションのビューでもあります。 そのミューテーター メソッドは、前述のように をスロー UnsupportedOperationExceptionしますが、読み取りとクエリのメソッドはバッキング コレクションに委任されます。 その結果、バッキング コレクションへの読み取り専用アクセスが提供されます。 これは、コンポーネントが内部コレクションへの読み取りアクセスをユーザーに提供する一方で、そのようなコレクションを予期せず変更できないようにするのに役立ちます。 変更できないビュー コレクションの例としては、および 関連するメソッドによってCollections#unmodifiableCollection Collections.unmodifiableCollectionCollections#unmodifiableList Collections.unmodifiableList返されるものがあります。
バッキング コレクションに対する変更は引き続き可能であり、変更できないビューを通じて表示される可能性があることに注意してください。 したがって、変更できないビュー コレクションは、必ずしも不変であるとは限りません。 ただし、変更できないビューのバッキング コレクションが実質的に不変である場合、またはバッキング コレクションへの唯一の参照が変更不可能なビューを介している場合、ビューは実質的に不変と見なすことができます。
<h2>"serializable">Collections</h2 のシリアル化可能性>
コレクションのシリアル化は省略可能です。 そのため、 インターフェイスを実装 java.io.Serializable するために宣言されているコレクション インターフェイスはありません。 ただし、シリアル化可能性は一般的に役立つと見なされるため、ほとんどのコレクション実装はシリアル化可能です。
パブリック クラス (や HashMapなどArrayList) であるコレクション実装は、実際にシリアル化可能な場合は、 インターフェイスをSerializable実装するように宣言されます。 一部のコレクションの実装は、変更できないコレクションなど、パブリック クラスではありません。 このような場合、このようなコレクションのシリアル化可能性は、それらを作成するメソッドの仕様、または他の適切な場所で説明されています。 コレクションのシリアル化可能性が指定されていない場合、そのようなコレクションのシリアル化可能性に関する保証はありません。 特に、多くのビュー コレクションはシリアル化できません。
インターフェイスを実装する Serializable コレクション実装は、シリアル化可能であるとは限りません。 その理由は、一般に、コレクションには他の型の要素が含まれており、一部の要素型のインスタンスが実際にシリアル化可能かどうかを静的に判断できないためです。 たとえば、シリアル化可能な Collection<E>とします。ここで E 、 は インターフェイスを Serializable 実装しません。 コレクションには、 のシリアル化可能なサブタイプ Eの要素のみが含まれている場合、または空の場合は、シリアル化可能な場合があります。 したがって、コレクション全体のシリアル化可能性は、コレクション自体が シリアル化可能 かどうかと、含まれるすべての要素もシリアル化可能かどうかによって異なるため、コレクションは条件付きでシリアル化可能と言われます。
と SortedMapのインスタンスでは、追加のSortedSetケースが発生します。 これらのコレクションは、セット要素またはマップ キーに順序を設定する を使用 Comparator して作成できます。 このようなコレクションは、指定 Comparator された もシリアル化可能な場合にのみシリアル化できます。
このインターフェイスは、 Java Collections Framework のメンバーです。
1.2 で追加されました。
の Java ドキュメント java.util.Collection。
このページの一部は、によって作成および共有され、に記載されている条件に従って使用される作業に基づく変更です。
プロパティ
| Handle |
基になる Android オブジェクトの JNI 値を取得します。 (継承元 IJavaObject) |
| IsEmpty |
要素 |
| JniIdentityHashCode |
ラップされたインスタンスの の |
| JniManagedPeerState |
マネージド ピアの状態。 (継承元 IJavaPeerable) |
| JniPeerMembers |
メンバー アクセスと呼び出しのサポート。 (継承元 IJavaPeerable) |
| PeerReference |
JniObjectReferenceラップされた Java オブジェクト インスタンスの を返します。 (継承元 IJavaPeerable) |
メソッド
| Add(Object) |
このコレクションに指定された要素 (省略可能な操作) が含まれていることを確認します。 |
| AddAll(ICollection) |
指定したコレクション内のすべての要素をこのコレクションに追加します (省略可能な操作)。 |
| Clear() |
このコレクションからすべての要素を削除します (省略可能な操作)。 |
| Contains(Object) |
このコレクションに |
| ContainsAll(ICollection) |
このコレクションに |
| Disposed() |
インスタンスが破棄されたときに呼び出されます。 (継承元 IJavaPeerable) |
| DisposeUnlessReferenced() |
このインスタンスへの未処理の参照がない場合は、 を呼び出 |
| Equals(Object) |
指定したオブジェクトとこのコレクションを比較して等しいかどうかを確認します。 |
| Finalized() |
インスタンスが終了したときに呼び出されます。 (継承元 IJavaPeerable) |
| ForEach(IConsumer) |
すべての要素が処理されるか、アクションによって例外がスローされるまで、 |
| GetHashCode() |
このコレクションのハッシュ コード値を返します。 |
| Iterator() |
このコレクション内の要素に対する反復子を返します。 |
| Remove(Object) |
指定した要素のインスタンスが存在する場合は、このコレクションから 1 つのインスタンスを削除します (省略可能な操作)。 |
| RemoveAll(ICollection) |
指定したコレクションにも含まれるこのコレクションの要素をすべて削除します (省略可能な操作)。 |
| RemoveIf(IPredicate) |
指定された述語を満たすこのコレクションのすべての要素を削除します。 |
| RetainAll(ICollection) |
指定したコレクションに含まれるこのコレクション内の要素のみを保持します (省略可能な操作)。 |
| SetJniIdentityHashCode(Int32) |
によって返される値を |
| SetJniManagedPeerState(JniManagedPeerStates) |
コレクション階層内のルート インターフェイス。 (継承元 IJavaPeerable) |
| SetPeerReference(JniObjectReference) |
によって返される値を |
| Size() |
このコレクション内の要素の数を返します。 |
| Spliterator() |
|
| ToArray() |
このコレクション内のすべての要素を含む配列を返します。 |
| ToArray(IIntFunction) |
指定された関数を使用して、このコレクション内のすべての要素を含む配列を |
| ToArray(Object[]) |
このコレクション内のすべての要素を含む配列を返します。返される配列のランタイム型は、指定された配列のランタイム型です。 |
| UnregisterFromRuntime() |
ランタイムが将来 Java.Interop.JniRuntime+JniValueManager.PeekValue の呼び出しから返されないように、このインスタンスの登録を解除します。 (継承元 IJavaPeerable) |
明示的なインターフェイスの実装
| IIterable.Spliterator() |
このコレクション内 |
拡張メソッド
| JavaCast<TResult>(IJavaObject) |
Android ランタイムチェック型変換を実行します。 |
| JavaCast<TResult>(IJavaObject) |
コレクション階層内のルート インターフェイス。 |
| GetJniTypeName(IJavaPeerable) |
コレクション階層内のルート インターフェイス。 |
| ToEnumerable(IIterable) |
コレクション階層内のルート インターフェイス。 |
| ToEnumerable<T>(IIterable) |
コレクション階層内のルート インターフェイス。 |