Listインターフェースは漏れやすい抽象化ですか？

を含む変数がある場合、その変数には、またはなどList、さまざまなタイプのオブジェクトが含まれる可能性があります。a とan の違いはかなり大きいです。メソッドのビッグO動作は大きく異なります。たとえば、をソートしてからバイナリ検索を実行することは完全に問題ありませんが、では意味がありません。ArrayListLinkedListLinkedListArrayListListArrayListLinkedList

そうは思いません。

漏れやすい抽象化は、抽象化することになっている実装の詳細に対処することを強制するものです。ただし、パフォーマンスは実装間で常に異なるため、リークと見なすと、リークのない抽象化はありません。

Listそれ以上のドキュメントがないものとして宣言されている場合、パフォーマンスに関する保証はないことを理解する必要があります。パフォーマンスを重視することを行う場合は、コピーを作成してそれを処理する必要があります。

また、多くの場合、機能が十分であり、パフォーマンスについて多くの仮定をするように誘惑しない、より一般的なインターフェイスがあることを忘れないでくださいCollection。

重要な抽象化はすべて、ある程度、漏れやすいものです。そうは言っても、それがここに当てはまるかどうかは本当にわかりません。:-)

抽象化は振る舞いに関係しています。振る舞いが特定のパフォーマンスを指定しない限り（Java Listはそうではありません）、それは実装の詳細です-つまり無関係です。

Javaでは、ドキュメント以外のインターフェースの最小パフォーマンスを指定することはできません。また、どの言語を使用するかについては知りません。コンパイラが検証するのが非常に難しい（不可能ですか？）でしょう。パフォーマンスが問題になる場合は、いくつかのオプションを確認できます。

1. リストインスタンスが属するクラス/インターフェースにドキュメント化します。
2. BinarySearchPerformantListさまざまなメソッドのパフォーマンス要件を指定する新しいインターフェイス（たとえば（yuck！））を作成します。

オプション2はおそらくより優れた抽象化ですが、追加のオーバーヘッドが伴います。

Javaには、一般に一定のランダムアクセス時間（O（1）get、putなど）を持つリストとして定義されるRandomAccessインターフェイスがあります。モジュールにこれらのパフォーマンス特性のリストが必要だと思われる場合は、RandomAccessではなくを使用することを検討してくださいList。その変更を行う必要性を感じない場合（そして変更を加える必要がない場合）、Listはそれほどリークが多いとは言えません。

あなたは正しいです、リストは漏れやすい抽象です。STLは概念の概念を使用して、この特定の問題をモデル化します。この例を使用するには、LinkedListがForward Iteratorをモデル化するのに対し、ArrayListモデルはRandom Access Iteratorをモデル化します。コンセプトが異なればパフォーマンス要件も異なるため、異なるアルゴリズムに適しています。