Hatena::Groupcatalyst

dann@catalyst このページをアンテナに追加 RSSフィード

2008-02-14

メタフレームワークという選択肢

01:57 |  メタフレームワークという選択肢 - dann@catalyst を含むブックマーク はてなブックマーク -  メタフレームワークという選択肢 - dann@catalyst  メタフレームワークという選択肢 - dann@catalyst のブックマークコメント

フレームワークは制御の逆転があるからフレームワークなわけで、prototype.jsはフレームワークじゃなくてライブラリなんですよね。

ライブラリは制御の流れを自分がコントロールできるから、背後の思想を理解しなくていい分、使う側は楽。一方、フレームワークは、制御の流れが逆転する分、その枠組みの中で作らなきゃいけないわけで、設計思想がわからないとつらい。設計思想がわかれば、すばらしいよねと思えるフレームワークもある。ただ、設計思想がわかってもつらいというフレームワークも数多くあって、Java界隈にはそういうフレームワークがとても多かった。

Strutsは、なんでこんなに複雑な設定ファイルを書かなきゃいけないのという、全くもって理解に苦しむフレームワークの一つなわけで、多分そういうところから入っちゃうと、フレームワークによる制約の強さとフレームワークのつくりの悪さの問題で、そもそもフレームワークの有り難味が理解できない。チームで使えば少しは有り難味がわかっても、個人で出来の悪いフレームワークを使えば、なおさら理解できないんじゃないかと思う。

Catalystは、その点ガチガチな規約はないし、どのレイヤもプラグインで切り分けられるから、フレームワークによる制約というのはさほど強いわけではない。だから、フレームワークがあるから実現できないってことは特にない。フレームワークによる制約を避けたければ、Catalystのようなメタフレームワークを使うという選択肢はある。

#ただ、ダメフレームワークといったって、大概の場合オレオレフレームワークよりはよっぽどいい。それくらいフレームワークのデザインは難しい。これはStrutsだってそう。大枠を作るのが大変なのはあるし、それを細部まで完璧にデザインしきるのは本当に難しい。だから、Strutsが使いずらいとか色々なことはあっても、それでも良くできているし、世間で使われるフレームワークの最初の一歩を作ったっていう点で、Strutsの功績は計り知れないものがあるよねというのは、書いておきたいなぁ。

トラックバック - http://catalyst.g.hatena.ne.jp/dann/20080214