誰かが何か考えを持っていますか、 AbstractList(およびArrayList)のremoveRangeメソッドがなぜですか?非常に明確で便利な操作のように見えますが、それでも、それを使用するには、List実装をサブクラス化する必要があります。protected
隠された論理的根拠はありますか?私にはまったく説明できないようです。
誰かが何か考えを持っていますか、 AbstractList(およびArrayList)のremoveRangeメソッドがなぜですか?非常に明確で便利な操作のように見えますが、それでも、それを使用するには、List実装をサブクラス化する必要があります。protected
隠された論理的根拠はありますか?私にはまったく説明できないようです。
はい、それは外部コードから範囲を削除する方法ではないためです。代わりに、これを行います。
list.subList(start, end).clear();
これは実際removeRange
には舞台裏を呼び出します。†</sup>
OPは、なぜパブリックAPIremoveRange
の一部ではないのかを尋ねます。List
その理由は、Effective Java 2nd edのアイテム40に記載されており、ここで引用します。
過度に長いパラメータリストを短縮するには、3つの手法があります。1つは、メソッドを複数のメソッドに分割することです。各メソッドは、パラメーターのサブセットのみを必要とします。不注意に行うと、メソッドが多すぎる可能性がありますが、直交性を高めることでメソッド数を減らすこともできます。たとえば、
java.util.List
インターフェイスについて考えてみます。サブリスト内の要素の最初または最後のインデックスを見つけるメソッドは提供されていません。どちらも3つのパラメーターを必要とします。代わりに、 2つのパラメーターを受け取り、サブリストのビューsubList
を返すメソッドを提供します。このメソッドは、それぞれが単一のパラメーターを持つorメソッドと組み合わせて、目的の機能を生成できます。また、indexOf
lastIndexOf
subList
メソッドは、インスタンスを操作する任意のメソッドと組み合わせてList
、サブリストに対して任意の計算を実行できます。結果として得られるAPIは、非常に高いパワーウェイトレシオを備えています。
removeRange
それほど多くのパラメータを持たないため、おそらくこの処理の候補ではないと主張することができますが、をremoveRange
介して呼び出す方法があることを考えると、冗長なメソッドでインターフェイスsubList
を乱雑にする理由はありません。List
†</sup>AbstractList.removeRange
ドキュメントには次のように書かれています。
このメソッドは
clear
、このリストとそのサブリストの操作によって呼び出されます。リスト実装の内部を利用するためにこのメソッドをオーバーライドすると、このリストとそのサブリストでの操作のパフォーマンスを大幅に向上させることができます。clear
また、OpenJDKのとの実装も参照してAbstractList.clear
くださいSubList.removeRange
。