フレームワークと制約
トラックバックをいただいて、いろいろ考えを深めることができました。文章化できるほど考えがまとまっていないので、思いつくまま箇条書きにします。
- 大前提として、フレームワークの機能面における制約とコーディングスタイルにおける制約は別物なので、混同しないように注意が必要。ここで話題にするのは後者。
- フレームワークとは枠組み。枠=制約があるからこそのフレームワーク。
- 制約の強さと自由度の高さは、トレードオフの関係*1。
- 制約の強さをX軸、開発効率をY軸に取ると、グラフは山型のカーブを描く。開発効率が極大となるように適切な制約の強さを見極めるのが、フレームワーク設計者の腕の見せどころ*2。
- 制約の強さは、IDEの支援に直結する(ことが多い)。
- 自由度の高さを優先すると、IDEの支援に弱みが出る(ことが多い)。その弱点は何で補完するか?プラグインの提供、ドキュメントの充実といったところだろうか。
- 規約ベースのフレームワークの思想って、Duck Typingの思想なんだなあと思った。
- 仕様の公開の方向性は外部(ユーザ側)を向いているのが本来の姿、という考え方には納得できる。ただ一方で、Observerパターンのように逆転例もあるので、要は使いどころなんだと思う。