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 は、このインターフェイスの直接的な実装を提供しません。これは、より具体的なサブインターフェイスの実装をSetList提供します。 このインターフェイスは、通常、コレクションを渡し、最大限の一般化が必要な場合にそれらを操作するために使用されます。
バッグ または マルチセット (重複する要素を含む可能性がある順序なしコレクション) は、このインターフェイスを直接実装する必要があります。
すべての汎用 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が含まれている場合にのみ返trueされます。."(o==null ? e==null : o.equals(e)) この仕様は、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#synchronizedCollection Collections.synchronizedCollectionCollections#unmodifiableCollection Collections.unmodifiableCollectionによって返されるラッパー コレクションが含Collections#checkedCollection Collections.checkedCollectionまれます。 ビュー コレクションのその他の例には、同じ要素の異なる表現を提供するコレクションが含まれます。たとえば、指定されている List#subList List.subListとおりに 、 NavigableSet#subSet NavigableSet.subSetまたは Map#entrySet Map.entrySet. バッキング コレクションに加えられた変更は、ビュー コレクションに表示されます。 それに対応して、ビュー コレクションに加えられたすべての変更 —変更が許可されている場合は >はバッキング コレクションに書き込まれます。 これらは技術的にはコレクションではありませんが、バッキング コレクションへの変更のIteratorListIterator書き込みを許可することも可能であり、場合によっては、バッキング コレクションへの変更は反復処理中に反復子に表示されます。
<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.unmodifiableCollectionCollections#unmodifiableList Collections.unmodifiableList返されるものがあります。
バッキング コレクションに対する変更は引き続き可能であり、変更できないビューを通じて表示されることに注意してください。 したがって、変更できないビュー コレクションは、必ずしも変更できないとは限りません。 ただし、変更できないビューのバッキング コレクションが実質的に変更できない場合、またはバッキング コレクションへの唯一の参照が変更不可能なビューを介している場合、ビューは実質的に不変と見なすことができます。
<h2>"serializable">Serializability of Collections</h2>
コレクションのシリアル化可能性は省略可能です。 そのため、インターフェイスを実装 java.io.Serializable するために宣言されているコレクション インターフェイスはありません。 ただし、シリアル化可能性は一般的に役立つと見なされるため、ほとんどのコレクション実装はシリアル化可能です。
パブリック クラス ( ArrayList または HashMap) であるコレクション実装は、実際にシリアル化可能な場合は、インターフェイスを Serializable 実装するように宣言されます。 一部のコレクションの実装は、変更できないコレクションなど、パブリック クラスではありません。 このような場合、そのようなコレクションのシリアル化可能性は、それらを作成するメソッドの仕様、または他の適切な場所で記述されます。 コレクションのシリアル化可能性が指定されていない場合、そのようなコレクションのシリアル化可能性に関する保証はありません。 特に、多くのビュー コレクションはシリアル化できません。
インターフェイスを実装するコレクション実装 Serializable は、シリアル化可能であるとは限りません。 その理由は、一般に、コレクションには他の型の要素が含まれており、一部の要素型のインスタンスが実際にシリアル化可能かどうかを静的に判断できないためです。 たとえば、インターフェイスを実装しないシリアル化可能な Collection<E>場所 E を Serializable 考えてみましょう。 コレクションにシリアル化可能なサブタイプの要素のみが含まれている場合、または空の E場合は、コレクションをシリアル化できます。 したがって、コレクション全体のシリアル化可能性は、コレクション自体がシリアル化可能かどうか、および含まれるすべての要素もシリアル化可能かどうかによって異なるため、コレクションは条件付きでシリアル化可能と言われます。
のインスタンスで追加の SortedSet ケースが発生します SortedMap。 これらのコレクションは、セット要素またはマップ キーに順序を設定する a を使用 Comparator して作成できます。 このようなコレクションは、指定 Comparator されたコレクションもシリアル化可能な場合にのみシリアル化できます。
このインターフェイスは、Java Collections Framework の メンバーです。
1.2 で追加されました。
の Java ドキュメントjava.util.Collection
このページの一部は、Android オープンソース プロジェクトによって作成および共有され、クリエイティブ コモンズ 2.5 属性ライセンスに記載されている条件に従って使用される作業に基づく変更です。
プロパティ
| Handle |
基になる Android オブジェクトの JNI 値を取得します。 (継承元 IJavaObject) |
| IsEmpty |
要素 |
| JniIdentityHashCode |
ラップされたインスタンスの |
| JniManagedPeerState |
マネージド ピアの状態。 (継承元 IJavaPeerable) |
| JniPeerMembers |
メンバー アクセスと呼び出しのサポート。 (継承元 IJavaPeerable) |
| PeerReference |
ラップされた Java オブジェクト インスタンスの a 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() |
|
拡張メソッド
| JavaCast<TResult>(IJavaObject) |
Android ランタイムチェック型変換を実行します。 |
| JavaCast<TResult>(IJavaObject) |
コレクション階層内のルート インターフェイス。 |
| GetJniTypeName(IJavaPeerable) |
コレクション階層内のルート インターフェイス。 |
| ToEnumerable(IIterable) |
コレクション階層内のルート インターフェイス。 |
| ToEnumerable<T>(IIterable) |
コレクション階層内のルート インターフェイス。 |