DODAIブログ – 08.自由の代償


DODAI

執筆:M.K

自由の代償

若いうちは自由に憧れるものだ。反抗する自由、壊す自由、作り上げる自由。

しかし自由を行使したからにはその責任が付きまとう。プログラミングも同じだ。自由な設計、自由な命名規則はメンバー間の知識の共有を困難にし、デバッグを難しくする。

デザインパターンなどは設計の部分で自由を制限する。コーディング規約はプログラミングにおける自由を制限してトレードオフとして利益を得る。自由を制限することによりパターン化、情報の共有が進むのだ。

ドダイでは名前オリエンテッドプログラム(なんだそりゃ)を推奨する。命名規約は絶対であり環境によって強制される。名前さえきちんとつければドダイが名前から連想される部分を自動的に処理してくれるのだ。

O/Vマッピングの回で紹介したaspxとデータのマッピングはその一つだ。今回はデータベースのテーブル設計についての名前オリエンテッドを紹介しよう。

行を一意に決定するためには自動採番のカラムがあると便利だ。ドダイではuidという名前のカラムがあればそのカラムを使って行を一意に決定する。ドダイのように自動生成を多用する場合、必ずuidでそのテーブルの行が特定できるというのはコードを劇的に簡単にする。

ほかにはcreated_date,updated_date,creted_user,updated_userというカラムがあればそれぞれ更新時間、更新者が自動的に設定される。わざわざプログラマが設定する必要はない。is_deletedカラムがあれば論理削除が自動的に実装される。display_orderがあれば・・・以下同文。

またRDBを使用したアプリケーションではオプティミスティックロックが必要になる。updated_dateカラムがあればこのフィールドが自動的に使用される。これはDataSetのように全部のレコードを比較する必要がないので高速でもある。

しかしこんな私も不安になった時期がある。名前を強制するなんてカッコ悪いし王道じゃないのではないか?これっていいの?

そんな私のすべての不安を吹き飛ばしてくれたのはRubyOnRailsだ。なんとActiveRecordの世界ではドダイと同じくカラム名をベースにO/Rマッピングが行われているのだ。なんて偶然!同士よ!

…っえ、決してパクリじゃありませんよ?信じてー