もっと形式的に出来ないか
プログラミングは好きだけど同一物の反復は苦手です。
アクションを書くのが嫌
アクションを書くのが嫌だ。心の底から嫌だ。本当に面倒だ。複雑なロジックを呼び出しているならまだしも、フォームで入力した値を元にごにょごにょして最後にデータベースに突っ込む、そんな処理を毎回書くのって苦痛だ。
乱暴に言ってしまえば「ユーザが新規会員登録する」のと「友達の日記にコメントを書き込む」のって同じ処理ですよね？入力項目とかチェック内容とか格納先のテーブル諸々とかそれらのレコードの初期値をどうするとか些末な違いはあるだろうけど、ロジックとしては限りなく同一だと思う。そして同一のロジックが異なるクラスとして実装されているのは我慢ならない。
例えば単純な新規登録／一覧／変更／削除があるようなアプリ(Direct to Webでも作れそうな簡単な奴)を作る時に、「属性がまったく同じだがアイデンティティが異なるエンティティ」*1を扱うような場合でも、データアクセスからアクションまで一揃い別個に作りましょうという開発スタイルを取る事がある。一つはデータアクセス層から積み上げで作るからってのがあるし、あとはDIの自動登録と自動バインディングを利用する為の型情報を持たせる為に個別クラスで実装するという理由もある。これがとても無益に思えて仕方が無い。
数においてのみ異なるクラスは同一のクラスとして実装したい。同一のロジックは単一のクラスで実現したい。そうしないといつまでも同じプログラムを作り続けることになってしまう。それは嫌だ。何かクラスを作る度にそのクラス用のArrayListクラスを実装するようなものだ、と考えたら恐ろしくなる。
「意味」から「形式」へ
ArrayListは共通のものを使い回すのにActionやDaoやモデルクラスは毎回作るっていうのはどういうことなのかと考えていたのだけど、これって「クラスは現実のものを抽象化したもの」という素朴な発想によるものではないかと最近思っている。形式的には同一でも、現実世界での実体として異なるから、違うクラスとして実装しているんではないだろうか。
確かに、モデルとモデルクラス、テーブルとDtoが一対一で対応していれば分かり易いかもしれない。その方がクラスにはっきりと「意味」を持たせる事が出来る。でも、コンピュータはそんな外的な意味なんて知ったこっちゃないと思う。コンピュータは形式しか扱わない(言い方を変えれば、形式の総体がコンピュータにとっても意味であり本質だ。) そこでもっと「形式」というものを重視したプログラミングをする事ができれば、よりコンピュータをうまく働かせ、我々の手間を減らす事が出来るんじゃないかと思う。
Mac OS X用のObjective-Cフレームワークの一つに、Cocoa Bindingsというのがある。Cocoa Bindingsの中心的なクラスであるNSController(とそのサブクラス)は、データの操作の持つ形式的な面をうまく共通化することで実装の手間を省いている(例えばNSArrayControllerは選択/データの追加/絞り込み/並べ替えといった、リストに対する操作がクラス化されている。)
RESTの統一インタフェースもまた、意味ではなく形式に注目した手法なんじゃないだろうか。「リソース」というのはデータのあり方という以上に、プログラムインタフェースの取り得る数ある「形式」の一つということだと思う。リソースという切り口に限らず、横断的に統一的な操作体系を持たせようという動きは今後も続くと思う。
