Japan PLoPのパターン
明日はパネル討論があるので、パターンワーキンググループのホームページにアクセスしてみた。すると、なんと昔Japan PLoP*1向けに書いたO-R(Object-Relational)マッピングの設計パターンのペーパーが掲載されていることを発見した。
http://patterns-wg.fuka.info.waseda.ac.jp/japanplop/index.htm
自分はO-Rマッピングのフレームワーク開発を3回経験している。
1回目は1997年で、当時はまだ珍しかったJavaでサーバーアプリケーションを組むプロジェクトだった。IDEにはJBuilderのバージョン1(!)を使ったが、当時の16MBぐらいのメモリ容量では苦しかったことを思い出す。
2回目は1998年に担当した(.net以前の)Visual Basic 6を使ったプロジェクトである。この案件はVB6でサーバーアプリケーションを書くという面白い趣向で、VB6の言語仕様上、実装の継承を使えない制約が技術的には面白かった。
3回目は現在勤めている会社の自社フレームワーク開発である。集中的に開発したのは2001-2003年頃で、当時は会社の仕事がかなり忙しかったため、週末や冬休みなどによく自宅でコーディングをした。中島みゆきが黒部ダムで「地上の星」を歌った紅白歌合戦の時も、自宅でプログラミングしながら見ていたことを思い出す。このフレームワークは結構たくさんのプロジェクトで使ってもらった上、機能拡張も繰り返したので、O-Rマッピングについてかなり経験値が上がった。
Japan PLoP向けのパターンは2回目のプロジェクトの直後に書いたため、今読むとずいぶん未熟な感じがする。最初のPersisterパターンに書いたようなインテリジェントなドメインオブジェクトを作るやり方は情報の受け渡しが厄介になるので、POJOなどのValueオブジェクトを使うのが常套手段である。SQLの組み立ても、部分的な文字列生成だけでなく、検索条件も構造表現したり、異種DBMSの差異を吸収するなど、いろいろ工夫できるところだ。できればこれらのパターンについても書き直したいところだが、連載に追われる立場で、とてもそんな余裕はない。また最近のJ2EEの世界では、オープンソースのHibernateやS2Daoなど軽量で実践的なフレームワークが普及したため、こうしたデザインパターンを参考に独自フレームワークを作るケースはほとんどないだろう。
「完成パターン」として掲載していただいくのは名誉なことである。しかし今となっては時代錯誤な内容のため、かなり恥ずかしい。履歴として残すのが目的ならば「遺物パターン」あるいは「お蔵入りパターン」とでもしていただけないものだろうか。
一方、通貨のパターンの方は概念モデルなので、さすがに陳腐化してない。とはいえ、これも図の参照が壊れているし、最後の方のクラス図はわかりづらい。また、さっき眺めてみて、英語のタイトルのMultiple CurrencyがMultiple Currenciesでないといけないことに気づいてしまった。いやはや、昔書いた文章なんて見ない方が幸せかも..
