フレームワークを作るその前に
前回の日記（id:giuseppe:20070105）でごろうさんからもらったコメント
やばい！
完全に、バカ専用フレームワーク を作ってる気がする・・・。
でも、作れって言われるんだものー。でもでも、業務アプリという前提で考えた場合に、「飛躍的に自由なプレゼンテーション層」が望まれるかどうかは、微妙な所だと思っています。
勘違いさせてしまったかもしれませんが、curlのアプリケーションが全て素晴らしくリッチであるべき、などとは考えてないです。また、フレームワークをバカ向けに作ることに批判的なわけでもないです。開発が簡単なことに越したことはないわけで、むしろ（バカ専用とは言いませんが）簡単フレームワークには大いに賛成。とゆうかそもそもフレームワークの目的に開発の容易性がなくなることは考えられないでしょうし。
ここで僕が問題に思っていたことは、GUIアプリのために作るフレームワークとゆうのは、往々にして柔軟性や拡張性といったものを制限するものであるということ。そしてそれが簡単さを手に入れるためのトレードオフだとゆう認識があまり一般的でないと思えることです。*1
この理由は（僕の数少ない経験から考察するに）フレームワークと言った場合にWebアプリのそれをイメージしてしまう人が多いからだと思います。やっぱり例はStrutsなんですが、これはWebアプリの世界ではプレゼンテーション層の確固たるフレームワークとして名が通っているわけですが、これ自体はほとんどWebアプリの可能性を制限しません。別にStrutsを使うからといって柔軟性や拡張性が大きく損なわれることはないわけです。
リッチクライアントのフレームワーク*2と比べてStrutsがこのように汎用的な理由は、Webアプリの場合はそもそもその大前提に、HTTPやHTML、Webサーバといった制約があって、Strutsはその制約を素直に形にしているだけだからです。つまり、ユーザからの入力は全てHTTPリクエストという形に一本化され、そこからリクエストパラメータを抽出し、ビジネスロジックを呼び出してHTMLを生成するという普遍的なフローがサポートされます。*3
対して、curlでこれと同じ抽象度でフレームワークを作ろうと思った場合、WebアプリにおけるHTTPのような制約がないため、それに相当する制限を設けなければなりません。なので前回の日記では、
前提として自由な土台がある以上、プログラマの作業を単調なものにするためにはできることを限定することに努力の大半を注ぐことになります。
と書きました。
これはボトムアップな見方ですが、アプリケーションの要件から共通するパターンを洗い出してフレームワーク化するというトップダウンのアプローチも同じことです。どちらにせよ、パターン化する、標準化する、制限する、など言い方は様々ですが、もとある自由度を狭めてプログラマの選択肢を減らすことによって簡単さを手に入れるということです。そして、得てしてこのトレードオフが（関係各位に）十分理解されないままフレームワークの構築が進んでしまい、合意のとれないレベルまで
柔軟でユーザフレンドリな画面というリッチクライアントの魅力を殺すことに繋がる
のが問題だと言いたかったんですが、言葉足らずでした。
お茶の間の家電の場合、テレビは見れてもビデオの予約録画はできない、予約録画はできるけどパソコンは使いこなせない、という人は当然います。それはビデオやパソコンのメーカがいくら頑張ったとしても。テレビよりもビデオの方が利用者に対する操作の選択肢が多く、パソコンはそれよりも多いので。ならば再生専用ビデオデッキやWebブラウジング専用クライアントなどを提案するのです。フルスペックのビデオやパソコンには劣りますが、お年寄りでも使えるかもしれません。curlのフレームワークを考える場合もこれと同じで、使う機能を特定して簡単さを求める面があります。
ちなみに、柔軟性を最大限確保しつつ、適切な抽象化を行い、可能な限り開発が容易になる手段を提供すること、これはフレームワーク担当の腕の見せ所になるでしょう。同じスペックのビデオでも、リモコンや操作パネルの設計で使いやすさに差をつけられます。
