読者です 読者をやめる 読者になる 読者になる

uehaj's blog

Grな日々 - GroovyとかGrailsとかElmとかRustとかHaskellとかFregeとかJavaとか -

不完全な抽象化としてのORマッピング

Joel on softwareの本を最近やっと読みました。いい本ですねこれは!!わりと最近の事情とかが織り込まれているので、ソフト開発の関係者なら、近年のソフトウェアエンジニアリング一般教養を最低限はフォローするのに適した本だといえましょう。Webの記事はよみましたが、本のほうとして読んでおく価値があるでしょう。

この中で出てくる概念なのですが、「不完全な抽象化」というのがあって、抽象化は良いけど、自明でない抽象化については必ずその下の下位層の理解が必要になる。結局それで、下位層を理解しなくて良い訳ではないよ、ということになる、ということです。

思ったのは、「ORマッピング」は、正に不完全な抽象化なのだよなあ、ということです。

Joelは、ただ、「不完全な抽象化がいけない」と言ってるわけではなくて、その存在を認識しておけよ、ということを言っているのだと私は解釈しました。理想的なのは、下位層を理解したうえで、いつそれが破れても良い覚悟(と直すスキル)を持って、その「不完全な抽象化」を使うということです。その上で抽象化による利便性は十分に享受する、と。

問題は、抽象化された上位レベルしか知らずに、「下位層を知らなくても良いのだ」と考えるというメンバが開発してしまうことで、破壊的なダメージをもたらす、ということです。ORマッピングの例で言うと、SQLやRDBMSの常識を知らずに、Hibernateで隠蔽されたオブジェクトを通じてシステムを作ってしまうことです。そのようなシステムは最終的にはまともな性能を発揮することはないでしょうし、その修正には眼もくらむようなコスト(有形無形の)がかかることでしょう。このような事態は、最高優先度で避けるべきです。

とはいえ、使う側・費用対効果の問題として言うと、「DBMSの熟練した経験者でありかつ熟練した Hibernateの経験者」を集める・育てるのは相当な覚悟(OR/AND高い単金)が必要です。技術取得が1段階余計にかかりますからね。また、SQLのエクスパートは、そうなればなるほど、ORマッピングツールなんか(まだるっこしくて)使いたがらないものです。動機の面でも問題があるということです。

ということで思ったのは、

「ORマッピングツール利用者のためのRDBMS入門」

があるといいなあと。Hibernateバリバリ利用なシステムを作るときに、とんでもないシステムにならないようにするためのRDBMSの最低限の知識入門。生のDBMSではなくて、「ORMツールを通じて見たときのRDBMSの挙動」を過不足なく解説する書籍(もしくは文書)があるといいな。あるいは

「GORMで学ぶRDBMS入門」

とかね。
私にはスキルがなくて書けませんけれども…。


Joel on Software

広告を非表示にする