デザインパターン勉強中（１）

そんなわけでデザインパターンの勉強を始めました。

勉強してわかったことをこつこつブログにまとめていきたいと思います。

ちなみに勉強に使っている本はこの本です。

最初から混乱しました。

前に読んだOPPの本では、良い設計の原則として「クラスをお互いに依存させないこと」が挙げられていたのですが、このパターンには思いっきり相互に依存し合うクラスが出てきます。

それがConcreteAggregate（具体的な集合体）クラスと、ConcreteIterator（具体的な反復子）クラスです。

「集合体クラスが修正されたら、反復子クラスにも修正が必要じゃん。何が便利なのこれ？」と思ったのですが、このパターンのキモは「集合体の実装を、それを実際に使う処理から隠すこと」のようです。

この本に載っている例では「本棚」が挙げられ、本棚クラスに収められている本が何であるかをひとつずつ数え上げるプログラムが記載されています。

例えば本棚に収められている本をfor文で順に表示しようとすると、以下のような本棚クラスの実装を数える側のプログラムが把握しなければなりません。

こうなってしまうと、本棚クラスの実装が変更された場合に、それを参照している箇所は修正が必要になってしまいます（配列ではなくArrayListになった場合など）。

それが複数箇所に及んでいた場合は……修正漏れが発生することは容易に想像できます。

そこで反復処理される集合体クラスの実装を、反復子クラスで隠してしまう、というのがIteratorパターンのキモのようです。

このパターンを用いることにより、実際に反復処理する側のクラスは、本棚の実装を気にする必要がなくなります。

本棚が配列だろうとListだろうと、サイズがいくつだろうと関係なく、反復子クラスが全部数えてくれるからです。

反復子クラスは本棚のクラスに合わせて作る必要がありますが、逆に言えばそれだけでいいとも言えます。

何箇所で本棚を参照していても、反復子クラスで反復処理を実装していれば、本棚クラスが修正されても問題ありません。

つまり「『本棚を見る側の処理』と『本棚』の依存関係を解消すること」がIteratorパターンのいいところなのではないでしょうか。

そのメリットのためであれば、集合体と反復子が依存しあっているのも、さして問題にならないですね。

また勉強したら更新します。