フレームワークと制約

トラックバックをいただいて、いろいろ考えを深めることができました。文章化できるほど考えがまとまっていないので、思いつくまま箇条書きにします。

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

*1:「制約」の対義語を「自由」と考えると、当たり前のことかも。

*2:ただし、開発効率曲線はコンテキスト(開発規模、開発者スキル、etc)に依存するので、極大点の絶対的な解はない。