Iterator - libnitsuji.so

今度はデザインパターンに手をつけはじめました。あいかわらずふらふらしてます。
教科書は増補改訂版Java言語で学ぶデザインパターン入門ですね。定番。デザインパターンは昔にちょこっと手を付けたことがあるので有名なやつは知ってはいるのだけれど、本当の意味でわかっているかっていうのはまた別の話です。なぜこのようなパターンがあるのか、どのようなところに使うのか。とか。
どうせすぐに飽きるはずなので、本に載ってるのを全部やるぜ！とか、全部ここに書くぜ！とかはもう言わない。

今日はIteratorです。Perlで実装しました。
http://svn.takatoshi.dyndns.org/public/pattern/trunk/iterator/
同じことをやってる人はたくさんいるのだろうけど、あえてそういうお手本は見ないことにした。自分の頭で考える。で、とりあえずテキトーに実装してmain.plを書いて実行したらあっさり実行でき、予想通りの結果が出てしまったのですが、正直それに驚いた。あー、これで動くのね、という感じ。そしてそのあとでIteratorを使わなかったらこの例題をどう実装するかな、と思って書いてもみた（nodesign.pl）。それで思ったのは「Iterator使わない方が断然ラク」ということだった。やはり。まあ、我ながらありがちな感想ではある。
いろいろ考えてみたんだけど、コレクションクラス（Aggregate）とそれを数え上げるクラス（Iterator）を分離することで、それを使う側は、

コレクションクラスの実装を知らなくていい
Iteratorという統一されたインターフェースを使用できる

というメリットがあるのですね（教科書に書いてあることまんまですが）。そして逆にそれだけと言える気もする。
短いプログラムはハッシュと配列を使って管理すればいい。長いプログラム、とりわけ複数のファイルに別れていたりするものの場合は、モジュール（クラス）を用意した方が効率的だし、そこでコレクションの要素に順次アクセスしたい場合はやっぱりIteratorが登場するのかな。
また、Webアプリはデータベースが絡んでくるので、そうするとどうなるんだろう。わからん。順次アクセスってあまりやらない気もするし。O/Rマッピングってやってないからよくわからんな。いや、そうじゃないな。やるかも。

while (my $book = $sth->fetchrow_hashref) {
    # do something
}

みたいなループがそうか。いやー、でも違うか。ハッシュのリファレンスを一個ずつ取り出すんだもんな。いや、やっぱこれか。もどかしいな。これが近いけどちょっとちがう。なぜなら$bookがクラスじゃないから、かな。でもIteratorが操作する対象であるAggregateクラスがない、と考えると違う気もする。あー、AggregateクラスはDBのテーブルなのかも。1つのレコードが1つのインスタンス（Bookクラスの）だと考えるとなんだかしっくりくる気もするな。ふむ。思いつきでいきなり「Webアプリは・・・」とか書き出してしまったところもあり。ちょっと答えが出ない。
（（ここをもっと考えること））
こんなところで。ちょっともどかしさが残るけどこれ以上考えても今はダメな気がするので終了ー。

Iteratorの実装の見本。
tieを使ってるのでちょっと高度（に見える）。
freeml byGMO
はてなの近藤さん。ほとんどおなじ。
http://hatena.dyndns.org/~jkondo/DesignPattern/Iterator/
CPAN。ぜんぜん違う。長い。わからん。
Iterator - A general-purpose iterator class. - metacpan.org

MFCのコレクションの場合。やりかたがちょっと違うかな。iterateしたくなるたびに毎回MSDNを調べていた記憶が・・・。
Microsoft API and Reference Catalog