Closed4
Iterator パターン
Iterator パターン適用フロー
STEP1: 適用に値する状況かどうかを確認する
以下いずれかなら次のステップに進む。
- コレクションのデータ構造が複雑で、その複雑さをクライアントから隠蔽したい
- コレクションを走査するロジックの重複を減らしたい
- 複数の具象コレクションを統一されたインターフェイスで探索したい
- コレクションの型が事前にわからない、あるいはわからないようにしたい
STEP2: メリット > デメリットであることを確認する
メリット
- 単一責任の原則に準じる
- 探索アルゴリズムがイテレータに抽出されるため、クライアントやコレクションにそれらの知識が漏れ出ない
- 開放閉鎖の原則に準じる
- 新しい種類のコレクションとイテレータを実装して既存のコードに低コストで組み込める
- 各イテレータが走査に関する状態を持っているため以下が可能
- 同じコレクションを平行して反復できる
- 反復を一時中断して必要な時に再開できる
デメリット
- 単純なコレクションなら過剰設計になる可能性がある
- コレクションのデータ構造によっては、イテレータを使うと、要素を直接見にいく場合と比較して非効率になってしまう可能性がある
STEP3: コードを書く
イテレータインターフェースを宣言
コレクションから次の要素を獲得するためのメソッドは必須。
しかし、前要素の獲得、現在位置の確認、探索終了チェックなど、いくつかの他のメソッドを追加してもよい。
コレクションインターフェースを宣言
イテレータ取得メソッドを宣言する。
戻り値の型はイテレータインターフェース。
イテレータ取得メソッドは複数あってもよい。
具象イテレータを実装
具象コレクションはnew
しない。
単にコンポジットするだけ。
具象コレクションを実装
具象イテレータを取得する公開メソッドを実装する。
その際、具象イテレータのコンストラクタに自身を渡す。
Iterator パターンの現実的な実装例
参考リンク
ここに書いてあることから多く影響を得ている。
上記は和訳が少しわかりづらいのでデザインパターンを全く知らない人は以下を通読とするといい。
このスクラップは2023/09/29にクローズされました