長きに渡った集中連載もこれでひとまずは終了である。過去ログはこちらを見てね。最後に実装作業の計画についてまとめておこう。
現状の進捗としては、詳細設計が終わったというところである。そもそもこの連載が異常に早いペースでできたのは、そこそこ前から計画を温めていて、設計のメモを少しずつ書きためていたからだ。実装の詳細はKCのコードを見直してパクっただけだ。過去の自分のコードを読んでいくと、「なんつーダサい書き方をしているんだ」と情けなく思うことが多くありつつ、「昔の俺って意外に賢かったじゃん」と驚くこともたまにあり、なかなか新鮮である。C++03で書いてあるKCや、C++98で書いてあるTCや、それらのもっと前にC言語で書いてあるQDBMの実装は、今考えると小汚いコードなのだが、泥臭いことに真面目に取り組んでいて我ながら感心する。それを踏まえて、今回はもうちょいマシなコードを書きたい。それも未来に見直せばゴミなのかもしれないが。
簡単に実装できるオンメモリのDBM実装のプロトタイプが既にあるので、それを使ってDBMとしての機能性を確認するテストは既に書いていて、問題なく動作している。少なくともこの連載で言及した機能は網羅しているので、インターフェイスに致命的な問題があるということはないだろう。あとは、ハッシュデータベースとツリーデータベースとスキップデータベースのそれぞれの実装を書いてから、既存のテストに通せば良い。もちろん、実装毎に確認すべきコーナーケースは違ってくるので、それを突いたテストを逐次書き足していくことは必要だ。ファイルを抽象化したクラスはUNIX版に関してはもうできているので、処理系依存の作業はしばらくないはずだ。あとは設計通りに実装を書き足していけばきっと完成する。
C++のコードが完成したら、各種プログラミング言語のバインディングを書くという作業も待っている。KCの時からだいぶ経っているから、JavaもPythonもRubyもLuaも、処理系のAPIがかなり変わっていそうな気がして気が重い。Goとかもやるのかやらないのか。それに付随して、DBMのクラス毎にラッパーを作っていたら作業量が大変なことになるので、全てのクラスを統合的に扱うクラスが欲しくなる。コンストラクタやチューニングパラメータの指定などの細かい差異をうまいこと吸収して全ての機能を一つのクラスに詰め込む。そうすればそのクラスのラッパーだけ書けば済むので。
DBMってAndroidとかiOSで活躍できるシーンもあると思っているので、それらで簡単に使えるパッケージを作るという作業もやってみたくはある。その後に、Windows版を作ったりもしたい。そこまで気力が持つかは知らんけども。
ということで、DBMについての語りはこれで終わり。どれかの記事がStay Homeの暇つぶしにでもなっていたら幸いだ。実装作業は週末や夜中にちびちびやるので、そんなすぐには出てこないと思うが、そのうちきっと出てくるTkrzwにご期待ください。
