0

Javaのファイルシステムサブツリー上でイテレータを開発する必要があります。反復の進行中にファイルシステムの状態が変わる可能性があります（たとえば、新しいフォルダーやファイルが作成および削除されます）。したがって、イテレータは最初に階層のスナップショットをキャプチャし（たとえば、ツリーをクロールし、見つかったすべてのファイルの名前をリストに保存します）、次にスナップショットを反復処理する必要があります。

キャッシュを作成するコードをイテレータのコンストラクタに配置するのは良い考えかどうか疑問に思っています。別の方法は、そのための特別なメソッドを指定することです（名前付きinit）。

繰り返されるサブツリーのサイズと深さは非常に大きくなる可能性があるため、キャッシュには時間がかかります。さらに、IOExceptionsがスローされる可能性があります（Javaのコンストラクターから例外をスローするのが適切な設計手法であるかどうかはまだわかりません）。

一方、イテレータを初期化するための専用メソッドを作成すると、クライアントコードはイテレータインターフェイスの単なる実装としてイテレータを使用できなくなります。

クライアントコードは、トラバーサルの前にinitメソッドを呼び出す役割も果たします。hasNext/メソッドで最初にイテレータがnext初期化されていることを確認し、初期化されていない場合は、initその中からメソッドを呼び出すことができます。ただし、これは、これらのメソッドの最初の呼び出しが、クライアント側から見える理由がない限り、次のメソッドよりも大幅に遅くなることを意味します。

4

2 に答える 2

0

コメントで述べたように、私は2つのクラスに責任を分離することにします。1つはファイルシステムのスナップショットを取得するためのものであり（たとえばFileSystemSnapshot）、もう1つはそれを反復するためのものです。必要な柔軟性に応じてFileSystemSnapshot、イテレーターのコンストラクターでインスタンスを作成するか、コンストラクター引数として渡すことができます。最初の方向に進むと、クライアントはイテレーターをより柔軟に構成できるようになり、たとえば、ファイルシステムのスナップショットを作成するためのさまざまな戦略を計画している場合に役立ちます。モックやスタブを簡単に作成できるため、単体テストにも適しています。。ただし、クライアントにトラバーサルの詳細を認識させる必要があります（つまり、ファイルシステムをトラバースする前にキャッシュする必要があります）。2番目のアプローチを使用すると、この実装の詳細がクライアントから隠されますが、柔軟性が低く、テストが少し難しくなります（ここでは、メソッドを定義し、createFileSystemSnapshot()そのメソッドをモックして、テスト用に別のインスタンスを返すことができます）。依存性注入パターンを確認することもできます。

HTH

于 2012-12-14T11:38:41.933 に答える
0

コンストラクターでのキャッシュの作成は問題ないはずです。時間のかかる部分については、イテレータをどのように使用するかに基づいて決定する必要があります。キャッシュが完了するまでクライアントが反復できない場合、時間がかかるのがコンストラクターであるかinitメソッドであるかは関係ありません。これは、同期ブロック操作です。

キャッシュが終了する前に反復を開始できる場合は、キャッシュを実行するスレッドを開始できますが、これを考慮に入れるには、hasNext（）をオーバーライドする必要があり、hasNext（）またはnext（）のいずれかになります。待たされます。

于 2012-12-14T11:21:44.257 に答える