インターフェースに「オプションのメソッド」を使用してJavaコレクションが実装されたのはなぜですか？

Javaコレクションフレームワークを拡張する最初の実装中に、オプションとして宣言されたメソッドがコレクションインターフェイスに含まれているのを見て驚いた。実装者は、サポートされていない場合、UnsupportedOperationExceptionsをスローすることが期待されています。これはすぐに、貧弱なAPIデザインの選択肢として私を驚かせました。

Joshua Blochの優れた「Effective Java」の本を多く読んだ後、彼がこれらの決定に責任を負う可能性があることを知った後、本で支持されている原則と一致しなかったようです。コレクションと、「オプション」メソッドでコレクションを拡張するMutableCollectionの2つのインターフェイスを宣言すると、はるかに保守性の高いクライアントコードにつながると思います。

ここに問題の優れた要約があります。

2つのインターフェイスの実装の代わりにオプションのメソッドが選択された理由はありますか？

よくある質問には、答えを提供します。つまり、実装可能なオプションメソッドの各セットについて、変更可能、変更不可能なビュー、削除専用、追加専用、固定長、不変（スレッド用）など、必要なインターフェイスの組み合わせの爆発の可能性がありました。

Interface Segregation Principle当時は今ほど探求されていなかったように思えます。SOLIDとISPが品質コードの事実上の標準になる前は、その方法（つまり、インターフェイスにはすべての可能な操作が含まれており、不要なものに対して例外をスローする「縮退」メソッドがあります）。

一部の人々は「オプションのメソッド」を嫌うかもしれませんが、多くの場合、高度に分離されたインターフェースよりも優れたセマンティクスを提供します。とりわけ、オブジェクトは、その存続期間中に能力や特性を獲得したり、オブジェクト（特にラッパーオブジェクト）がどの正確な能力を報告すべきかをいつ構築するかを知らなかったりする可能性を考慮します。

優れたデザインのJavaコレクションクラスのパラゴンを呼び出すことはほとんどありませんが、優れたコレクションフレームワークには、その特性と能力についてコレクションに問い合わせる方法と共に、多数のオプションメソッドを基盤に含めることをお勧めします。このような設計により、基になるコレクションが持つ可能性のある機能を誤って不明瞭にすることなく、単一のラッパークラスをさまざまなコレクションで使用できます。メソッドがオプションではない場合、コレクションがサポートする機能の組み合わせごとに異なるラッパークラスを用意するか、状況によっては使用できないラッパーを用意する必要があります。

たとえば、コレクションがインデックスによるアイテムの書き込みまたは末尾へのアイテムの追加をサポートするが、アイテムの中央への挿入をサポートしない場合、実行されるすべてのアクションをログに記録するラッパーにそれをカプセル化するコードにはバージョンが必要ですサポートされている機能の正確な組み合わせを提供するロギングラッパーの場合、または利用できない場合は、appendまたはwrite-by-indexのいずれかをサポートし、両方はサポートしないラッパーを使用する必要があります。ただし、統合コレクションインターフェイスが3つのメソッドをすべて「オプション」として提供し、どのオプションメソッドが使用可能かを示すメソッドを含めると、単一のラッパークラスが機能の任意の組み合わせを実装するコレクションを処理できます。どの機能をサポートしているのかを尋ねられると、ラッパーはカプセル化されたコレクションがサポートしているものを単に報告できます。

「オプションの機能」の存在により、集約されたコレクションが、機能が実装の存在によって定義された場合よりもはるかに効率的な方法で特定の機能を実装できる場合があります。たとえば、concatenateメソッドを使用して他の2つの複合コレクションを形成するとします。最初のコレクションはたまたま1,000,000個の要素を持つArrayListであり、最後のコレクションは最初から反復できる20個の要素のコレクションでした。複合コレクションが1,000,013番目の要素（インデックス1,000,012）を要求された場合、ArrayListに含まれるアイテムの数（つまり1,000,000）を要求し、要求されたインデックスからそれを減算し（12を取得）、2番目から12の要素を読み取り、スキップできますコレクション、および次の要素を返します。

このような状況では、複合コレクションにはインデックスによってアイテムを瞬時に返す方法はありませんが、複合コレクションに1,000,013番目のアイテムを要求する方が、個々のアイテムから1,000,013個のアイテムを読み取り、最後を除くすべてを無視するよりもはるかに高速です1。

当時よく知らなかった元の開発者に起因すると思います。Java 2とCollectionsが最初にリリースされた1998年前後から、OO設計で大きな進歩を遂げました。明らかな悪いデザインのように見えるものは、OOPの初期にはそれほど明白ではありませんでした。

ただし、余分なキャストを防ぐために行われた可能性があります。それが2番目のインターフェイスである場合、コレクションインスタンスをキャストして、これらのオプションメソッドを呼び出す必要がありますが、これもまたugいです。今ではUnsupportedOperationExceptionをすぐにキャッチして、コードを修正します。ただし、2つのインターフェイスがある場合は、instanceofとキャストをすべての場所で使用する必要があります。おそらく彼らはそれを妥当なトレードオフだと考えたのでしょう。また、Java 2の初期の頃、instanceofはパフォーマンスが遅いためにひどく嫌われていました。彼らはそれを使いすぎないようにしようとしていました。

もちろん、これはすべて野生の憶測です。元のコレクションの建築家の誰もがチャイムを鳴らさない限り、私たちはこれに確実に答えることができるとは思いません。