Wednesday, February 06, 2008

Software::JINKOU-MUNOU - MIU開発(3)

次は会話データのバイナリファイル構造だと思って,今日はそのファイルのレイアウトを考えていました.
インデックス領域とデータ領域にわけて,でインデックス領域にはこの情報とこの情報を書き込んで,
型はこいつはlongでこいつはshortで・・・と考えていたのですが.
あれ,これってなんか汎用性のある設計にできるんじゃね?とか思って
頭の中がジェネリックプログラマー化する私.
上のは完全に造語ですけど,ようはTemplate使ったジェネリックプログラミングをしたがる気分になったってことで.
だもんで設計するのは基底クラス.
どういうメソッドがあって,どういうクラスがあればいろいろと使いまわせるのか,というのを考え始めます.
言語がPerlでCPANモジュールを使わないという制限のもとですから,
標準以外のモジュールを使わずに実現できる方法を考えないといけません.

設計しているのはバイナリファイルをある一定のルールで読み書きする抽象クラス.
細かな処理はサブクラスに任せる.
なーんかDBMでも作ってる?とかいう気分になってきました.
DBMの詳細な設計なんて,専門外なので詳しくは知りませんが.
すばやく,コンパクトに,という点を念頭に置くのは共通しているんじゃないでしょうか.

考えているのが,基本的にインデックス領域とデータ領域の二種類の領域を読み書きできるクラス.
しかしMIUの場合,書き込みが完了したファイルに追加書き込みなんてしなくてもいいので,
書き込み専用,読み込み専用のクラスがあればいいのです.
ファイルを作るのはクライアント(ローカル)マシン,読み込むのはWebサーバマシンなので.
で,インデックスとデータ領域だけだったら,いわば1次元の配列,ハッシュでしかない.
n次元配列や,ハッシュを返すハッシュ,複数のメンバを持つ構造体みたいなのを
バイナリへ落としたいとかなると,インデックスとデータ領域,という考えじゃだめでして.
あ,Data::DumperやStorableを使えばいいじゃんとかいうのは無し.
必要なキーがそろっていれば,最小限のメモリ消費かつ最速で目的のデータにアクセスできなきゃいけない
という制約がある場合,一通りの(シリアライズ済み)データを読み込んでしまう上記のモジュールはちょっと,ね.
SDBMとかでしたらなんかオーバーヘッドでかそう.
一レコードの容量も確か制限があったような.

ということで,データ領域も,インデックス領域として置き換えることができれば,
複雑なデータ構造も保存できるんじゃないかと.
ん?となると結局木構造やん,汎用的な,ということになり.
先日書いたモジュールも,今書こうとしているモジュールで書き直せそうです.
一番最初に書いた,配列をバイナリに落とすモジュールも書き直せるかも.
配列やら何やらをバイナリに落とすモジュールがあるけども,
元をたどれば一つの基底クラスですよ,と.
なんかいいですねー.

そういう設計部分でうほうほしてしまっている私.
目標はMIU開発やっちゅーのにベクトルがずれてる気が.

No comments: