JavaコアのIteratorにおける単一責任の原則の違反

Question

remove()のインタフェースを持つjava.util.Iteratorのインタフェースはなぜですか？

確かにこの方法が必要であり、すべてがその存在に慣れてきたことがあります。しかし実際、イテレータの主目的は、アクセスコンテナ要素を提供することだけです。そして、誰かがこのインタフェース用に独自の実装を作成したい場合、要素を削除する機能を提供することができない、またはしたくない場合は、UnsupportedOperationExceptionを強制的にスローします。そして、その例外を投げることは、通常、あまりよく考えられていないアーキテクチャや設計上のいくつかの欠陥を示しています。

本当に私はそのような決定の理由を理解していません。そして、私はそれがより正確に任意の方法をサポートするための特定のサブインターフェイスを分離されるだろうと思います。

remove()がIteratorの一部である理由の任意の推論のバージョン？ SOLIDからの単一責任原則の直接違反のこの例ではありませんか？

Answer 1

ファンシーな技術的な回答に加えて...タイムラインも考慮してください。 90年代後半のある時点でロバート・マーティンによって「単一の責任原理」が発案されました。

Javaイテレータインタフェースは、Java 1.2で実現しました。

Sunの人々は、Javaの初期リリースで作業している間に、この概念について聞いたことがない可能性が非常に高いです。

もちろん、多くのスマートな人が同じアイデアを持っていますが、良いデザイナーは「SRP」を知らなくても「SRP」を実装しているかもしれませんが、このルールのすべての大小違反を公開する...

Answer 2

このデザインの決定はJava Collections API Design FAQで説明されています。具体的には、コレクションが不変性をサポートしておらず、代わりにオプションの操作が必要な理由に関する最初の質問を参照してください。簡単な答えは、インターフェイスの数が「爆発」したくないということです。

Answer 3

ここではセマンティクスが混在しているようです。 Robert C. Martinは、単一の責任を「変化する単一の理由」（SRP.pdf）と定義しています。 SRPは、の結束と非常に関連しています：ソフトウェアモジュールは、互いに機能的に関連しているものだけを含むべきです。

これらのことを念頭に置いて、私はIteratorに含まれているremoveメソッドがSRPに違反しているとは思いません。要素を削除することは、要素を反復処理している間にやりたいことがあります。操作は本質的に密接なものです。また、Iteratorで要素の削除を有効にすると、Iterableインターフェイス（Java 5で追加されたインターフェイス）がはるかに強力になります。この特徴は、例えば、多くの方法がGuava's Iterables utility classにあります。

アンクルボブ自身の用語の歴史についての詳細はthis excellent articleです。