フレームワークのジレンマとUrumaの目指すもの
ひがさんのところの、アーキテクト以外は「限定されたことだけやっとけ」という議論から。
私も技術者のモチベーション&技術力アップという観点から、より先を見せていくのに賛成。
ただ、そのやり方として段階が必要だと思うのです。
フレームワークを設計していると、常に汎用性と学習コストのジレンマに悩みます。
フレームワークとしてはできる限り汎用性を高くして適用可能領域を広く取りたい。一方で、フレームワークの価値は「縛りがあること」でもあります。縛りがあることで、フレームワーク利用者のできる範囲を狭め、そのことが学習コスト(=敷居の高さ)を下げる(やることが限定されているから、覚えることは少ない)。さらにフレームワーク利用者が作成する範囲が少ないので、品質が上がる(正確には下がりにくい)というわけです。
最初はこれでも構わないのですが、やりたいことが増えてくるとフレームワークの縛りが逆に足かせとなってしまい、「簡単なフレームワークだけどできることが少ない」となってしまうのです。
そもそも、フレームワークとはアーキテクチャや設計の再利用に他ならないので、枠があるのは当然。そこで、フレームワーク設計者としては、まず、その枠がどこにあるのかを明確にし、できること、できないことをハッキリさせなければならないのです。
そのうえで、
のどちらかの方向に偏らざるをえません。
敷居が低くかつ汎用性も高いフレームワークが良いのですが、この両立は非常に難しいので、どのあたりにバランスを取るべきか、がフレームワーク設計時のジレンマとなるわけです。
現実として JCP で議論されるような普及を目指すフレームワークは、汎用性に重きを置くので、どうしても複雑化して敷居が上がる傾向にあります。
さて、Seasar2のキラーアプリとなったS2Daoですが、これはこのジレンマをうまく解決しており、それが普及の一因になったと私は考えています。
S2Dao の素敵なところは、「2Way-SQL」という考え方。簡単なSLECT文などでは、わざわざSQLを書かなくてもFWが自動生成してくれることで「敷居の低さ」を実現。それで物足りない場合は直接SQLを指定することで「汎用性の高さ」を実現しています。
つまり、同じフレームワークの中でユーザが自然と敷居の高いところから入って、徐々に学習して使いこなせるようになるまでの段階をサポートしているのです。
当時対抗馬となっていた Hibernate と比べると、こんな感じの位置づけの違いになるでしょうか。
で、Urumaです。Urumaも、GUIフレームワークとしてS2Daoの思想を継承しています。たとえば、Eclipse-Plugin(RCP)は非常に汎用性が高いのですが、いかんせん敷居が高すぎます(国内では資料が少ないし、仕様もコロコロ変わる)。
Urumaは内部にRCPを内包して汎用性を高めつつ、利用者側にとっては最小限のコードでGUIを実現できるようにしています。
そして、徐々に高度なGUIを作りたくなってきたとき、RCP の提供する機能を極限まで利用できるようにする、というのがFWとしてUrumaの目指すところなのです。
