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- 派生
- 属性
- 実装
注釈
コレクション階層内のルート インターフェイス。 コレクションは、要素と呼ばれるオブジェクトの グループを表します。 重複する要素を許可するコレクションもあれば、許可しないコレクションもあります。 順序付けされていないものもあれば、順序付けされていないものがあります。 検出順序が定義されているコレクションは、通常、 SequencedCollection インターフェイスのサブタイプです。 JDK は、このインターフェイスの 直接 の実装を提供しません。 Set や Listなどのより具体的なサブインターフェイスの実装を提供します。 このインターフェイスは、通常、コレクションを渡し、最大限の一般化が必要な場合にそれらを操作するために使用されます。
バッグ または マルチセット (重複する要素を含む可能性がある順序なしコレクション) は、このインターフェイスを直接実装する必要があります。
すべての汎用 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 つの要素が含まれている場合にのみ、truee(o==null ? e==null : o.equals(e))を返します」と表示されます。 この仕様は、null 以外の引数Collection.containsでoを呼び出すと、要素o.equals(e)に対してeが呼び出されることを意味するものではありません。 実装では、最適化を自由に実装できます。そのため、最初に 2 つの要素のハッシュ コードを比較するなどして、 equals 呼び出しを回避できます。 ( Object#hashCode() 仕様では、等しくないハッシュ コードを持つ 2 つのオブジェクトが等しくできないことが保証されます)。より一般的には、さまざまな Collections Framework インターフェイスの実装は、実装者が適切と判断した場合でも、基になる Object メソッドの指定された動作を自由に利用できます。
コレクションの再帰的トラバーサルを実行する一部のコレクション操作は、コレクション自体が直接または間接的に含まれる自己参照インスタンスの例外で失敗することがあります。 これには、 clone()、 equals()、 hashCode() 、および toString() メソッドが含まれます。 実装では必要に応じて自己参照シナリオを処理できますが、最新の実装では処理されません。
<h2>"view">View コレクション</h2>
ほとんどのコレクションは、格納されている要素のストレージを管理します。 これに対し、 ビュー コレクション 自体は要素を格納しませんが、代わりに実際の要素を格納するためにバッキング コレクションに依存します。 ビュー コレクション自体によって処理されない操作は、バッキング コレクションに委任されます。 ビュー コレクションの例としては、 Collections#checkedCollection Collections.checkedCollection、 Collections#synchronizedCollection Collections.synchronizedCollection、 Collections#unmodifiableCollection Collections.unmodifiableCollectionなどのメソッドによって返されるラッパー コレクションがあります。 ビュー コレクションの他の例としては、 List#subList List.subList、 NavigableSet#subSet NavigableSet.subSet、 Map#entrySet Map.entrySet、 SequencedCollection#reversed SequencedCollection.reversedによって提供されるなど、同じ要素の異なる表現を提供するコレクションがあります。 バッキング コレクションに加えられた変更は、ビュー コレクションに表示されます。 それに対応して、ビュー コレクションに加えられたすべての変更 —変更が許可されている場合は >はバッキング コレクションに書き込まれます。 技術的にはコレクションではありませんが、 Iterator と ListIterator のインスタンスを使用すると、バッキング コレクションに変更を書き込むこともできます。場合によっては、バッキング コレクションの変更は反復処理中に反復子に表示されます。
<h2>"unmodifiable">Unmodifiable Collections</h2>
このインターフェイスの特定のメソッドは"破壊的" と見なされ、動作するコレクションに含まれるオブジェクトのグループを変更するという点で"ミューテーター" メソッドと呼ばれます。 このコレクションの実装で操作がサポートされていない場合は、 UnsupportedOperationException をスローするように指定できます。 このようなメソッドは、呼び出しがコレクションに影響を与えない場合に UnsupportedOperationException をスローする必要があります (ただし、必須ではありません)。 たとえば、 #add add 操作をサポートしていないコレクションがあるとします。 引数として空のコレクションを使用して、このコレクションで #addAll addAll メソッドが呼び出された場合はどうなりますか。 0 個の要素を追加しても効果がないため、このコレクションでは単に何もせず、例外をスローしないようにしても問題ありません。 ただし、特定のケースでのみスローするとプログラミング エラーが発生する可能性があるため、このようなケースでは例外を無条件にスローすることをお勧めします。
変更できないコレクションはコレクションであり、そのすべてのミューテーター メソッド (上記で定義) が指定され、UnsupportedOperationExceptionがスローされます。 したがって、このようなコレクションは、そのコレクション上のメソッドを呼び出すことによって変更することはできません。 コレクションを適切に変更できないようにするには、コレクションから派生したビュー コレクションも変更不可能である必要があります。 たとえば、リストが変更できない場合、 List#subList List.subList によって返されるリストも変更できません。
変更できないコレクションは、必ずしも不変であるとは限りません。 含まれている要素が変更可能な場合、変更できない可能性がある場合でも、コレクション全体が明らかに変更可能です。 たとえば、変更可能な要素を含む 2 つの変更不可能なリストを考えてみましょう。 両方のリストが変更不可能であっても、要素が変更されていた場合、 list1.equals(list2) を呼び出した結果は、次の呼び出しとは異なる場合があります。 ただし、変更できないコレクションに変更できない要素がすべて含まれている場合は、実質的に不変と見なすことができます。
<h2>"unmodview">Unmodifiable View Collections</h2>
変更できないビュー コレクションは、変更不可能なコレクションであり、バッキング コレクションに対するビューでもあります。 前述のように、ミューテーター メソッドは UnsupportedOperationExceptionをスローしますが、読み取りとクエリのメソッドはバッキング コレクションに委任されます。 その結果、バッキング コレクションへの読み取り専用アクセスが提供されます。 これは、コンポーネントが内部コレクションへの読み取りアクセスをユーザーに提供する一方で、そのようなコレクションを予期せず変更できないようにするのに役立ちます。 変更できないビュー コレクションの例としては、 Collections#unmodifiableCollection Collections.unmodifiableCollection、 Collections#unmodifiableList Collections.unmodifiableList、および関連するメソッドによって返されるものがあります。
バッキング コレクションに対する変更は引き続き可能であり、変更できないビューを通じて表示されることに注意してください。 したがって、変更できないビュー コレクションは、必ずしも不変であるとは限りません。 ただし、変更できないビューのバッキング コレクションが実質的に変更できない場合、またはバッキング コレクションへの唯一の参照が変更不可能なビューを介している場合、ビューは実質的に不変と見なすことができます。
<h2>"serializable">Serializability of Collections</h2>
コレクションのシリアル化可能性は省略可能です。 そのため、 java.io.Serializable インターフェイスを実装するために宣言されているコレクション インターフェイスはありません。 ただし、シリアル化可能性は一般的に役立つと見なされるため、ほとんどのコレクション実装はシリアル化可能です。
パブリック クラス ( ArrayList や HashMapなど) であるコレクション実装は、実際にシリアル化可能な場合は、 Serializable インターフェイスを実装するように宣言されます。 一部のコレクションの実装は、変更できないコレクションなど、パブリック クラスではありません。 このような場合、このようなコレクションのシリアル化可能性は、それらを作成するメソッドの仕様、または他の適切な場所で記述されます。 コレクションのシリアル化可能性が指定されていない場合、そのようなコレクションのシリアル化可能性に関する保証はありません。 特に、元のコレクションがシリアル化可能な場合でも、多くのビュー コレクションはシリアル化できません。
Serializable インターフェイスを実装するコレクション実装は、シリアル化可能であるとは限りません。 その理由は、一般に、コレクションには他の型の要素が含まれており、一部の要素型のインスタンスが実際にシリアル化可能かどうかを静的に判断できないためです。 たとえば、Collection<E>がE インターフェイスを実装しないシリアル化可能なSerializableを考えてみましょう。 コレクションには、 Eのシリアル化可能なサブタイプの要素のみが含まれている場合、または空の場合は、シリアル化可能な場合があります。 したがって、コレクション全体のシリアル化可能性は、コレクション自体が シリアル化可能 かどうか、および含まれるすべての要素もシリアル化可能かどうかによって異なるため、コレクションは条件付きでシリアル化可能と言われます。
SortedSetとSortedMapのインスタンスでは、追加のケースが発生します。 これらのコレクションは、セット要素またはマップ キーに順序を設定する Comparator を使用して作成できます。 このようなコレクションは、指定された Comparator もシリアル化可能な場合にのみシリアル化できます。
このインターフェイスは、Java コレクション フレームワークのメンバーです。
1.2 で追加されました。
このページの一部は、によって作成および共有され、に記載されている条件に従って使用される作業に基づく変更です。
プロパティ
| 名前 | 説明 |
|---|---|
| Handle |
基になる Android オブジェクトの JNI 値を取得します。 (継承元 IJavaObject) |
| IsEmpty |
この |
| JniIdentityHashCode |
ラップされたインスタンスの |
| JniManagedPeerState |
マネージド ピアの状態。 (継承元 IJavaPeerable) |
| JniObjectReferenceControlBlock |
コレクション階層内のルート インターフェイス。 (継承元 IJavaPeerable) |
| JniPeerMembers |
メンバー アクセスと呼び出しのサポート。 (継承元 IJavaPeerable) |
| PeerReference |
ラップされたJava オブジェクト インスタンスのJniObjectReferenceを返します。 (継承元 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() |
このコレクション内の要素に対して |
拡張メソッド
| 名前 | 説明 |
|---|---|
| GetJniTypeName(IJavaPeerable) |
インスタンス |
| JavaAs<TResult>(IJavaPeerable) |
|
| JavaCast<TResult>(IJavaObject) |
Android ランタイムチェック型変換を実行します。 |
| JavaCast<TResult>(IJavaObject) |
コレクション階層内のルート インターフェイス。 |
| ToEnumerable(IIterable) |
Java IIterableを反復処理するIEnumerableを返します。これにより、 |
| ToEnumerable<T>(IIterable) |
Java IIterableを反復処理し、各要素を |
| TryJavaCast<TResult>(IJavaPeerable, TResult) |
|