DCIが便利になるのはまだ時間がかかる

ぼんやりした随想であって、精密な議論ではありません。よくわからんけどよくわからんまま書くわ。あしからず。（一応付け足しとくけど、「DCIはエンドユーザのメンタルモデルを実装に落とし込むための設計パラダイム」だから云々とか言う気はないです。誰かがライブラリ作ってくれて実装に落としこむの楽になったら大歓迎です。）

DCIは今のプログラミングにおいては、そのメリットを生かし切れないように思う。というのは、今のプログラムはオブジェクトを使ったらGCに回収される、つまり、捨てるから。富豪！extendはいいとして、unextendする必要がない。現時点でもメンタルモデルの整理に役立ち、まぁまぁ生産性や保守性の向上は見込めるとは思うが、別に性能の向上に役立つ代物ではない。手法であって機能ではない。そもそもそんな主張は誰もしてないわけだが。

それはそれとして、手法から機能へ、つまり「物凄く便利」にまで評価が上昇する時が来ると思う。それは、MRAMなどの不揮発性メモリが普及した時。オブジェクトデータベースと共に猫も杓子もDCI使い出すのではないか。と思った。

不揮発性メモリ上のオブジェクトデータベースにはプレーンなオブジェクトを保存しておき、使うときにロールをextendし、役割を終えて何かアトリビュートの変更などがあった場合はunextendしてプレーンな状態で保存するって使い方。

どうか。どうだろな。適当。ぼんやり。

中間テーブルにidつけるとWeb APIが綺麗

なんかActiveRecordが中間テーブルにid付けるのに反対する人たまに見るんだけど、俺は付けた方がいいと思う。というのは、Web APIがすっきりするから。

例えば、followships って中間テーブルがあったとして、カラムに followee_id, follower_id って名前を付けるとしようじゃないか。（followship, followee 共に造語です。-shipsを付けて関係を表し、-ee を「される人」-er を「する人」に付けるのが個人的な趣味なのです。interviewee/interviewerの関係ね。話題が逸れるけど俺は書く！オススメはしません）

で、フォロワー作るときはいいとして、フォロワー削除するときのAPIにidナシとidアリじゃ違いが出るじゃんね。

DELETE /users/1/followships?followee_id=256&follower_id=1

＿人人人人人人人人＿
＞　かっこわるい　＜
￣Y^Y^Y^Y^Y^Y^Y￣

DELETE /users/1/followships/4

＿人人人人人人人＿
＞　かっこいい　＜
￣Y^Y^Y^Y^Y^Y￣

ActiveRecordってそもそもRailsで使うのが主目的じゃんすか。んで、Railsってウェブアプリケーションフレームワークじゃないっすか。なんで、Web APIが綺麗になるなら、データベースの領域とはいえ、一考に値すると思うんすよね。いかがか。