フレームワークとライブラリの違い

　たまに、フレームワークとライブラリの違いって何だ？どっちも共通部品じゃないの？って聞かれます。フレームワークもライブラリもどっちもプログラム作る前にできていて提供されるからみたいなんですが、「プログラムの流れの主動が異なる」とまずは説明します。プログラムの流れがフレームワークが主動になっているか、プログラマの作ったコードが主動になっているかということです。

　しかし、説明するにも単にStrutsなどのフレームワークを使っているだけのプログラマには、そもそもプログラムの主動がフレームワーク側にあるという意識すらない人もいますし、その感覚をなかなか理解してもらえないのも事実です。で、とりあえず「共通部品と考えていていいよ」って落ち着きます。（基盤と共通部品の違いって何？とか言うのと一緒）昔、その辺の、フレームワークとライブラリについて、立ち位置の違いで呼び方があったのを思い出したので、ちょっと調べてみたのを忘れないためにメモします。（基本的に検索して見つけた下記の参考URLにあったモノを自分の言葉としてまとめただけです）

　自分自身の中では前述のどちらが主動になるかによって「仕組み」を提供するのがフレームワーク、プログラマへの「機能（Ａを渡せばＢを返すとか）」を提供するのがライブラリと切り分けていますが、ライブラリと呼ばれているものの中にもフレームワークと呼ばれるものがありますのでその辺を質問されると「・・・」となってしまいます。また、仕組みって何だ？とか機能って何だ？って言われるともう何がなんだか・・・自分の感覚を説明するほど難しいことはないですね。

フレームワークには２種類ある（CallingとCalled）

　これはフレームワークから見た言葉になります。先の主動という話になるとCallingは「フレームワークがプログラムを呼ぶ」ということでフレームワーク主動、Calledは「フレームワークがプログラムに呼ばれる」ということでプログラマ主動。

Calledフレームワーク

　プログラムの主導権がプログラム側にあります。「Framework is Called by Your Program」の関係です。全体のプログラムの流れのなかでプログラマの呼び出したいときにフレームワークを呼び出すといった感じで使います。イメージとしては「みんなのために作った共通部品」などのようなライブラリに近いですが、HibernateやVelocityなどのCalledフレームワークと呼ばれるものは、まとまった「機能」を提供します。（O/RマッパはDB周りの機能一通りを提供するなど）

例
- Javaのコレクションフレームワークなど（List,Map,Set:オブジェクトに対するアクセス方法を提供する）
- Velocity（テンプレート文書を書き換えるという仕組みを提供する）
- Hibernate（DBとやり取りする仕組みを提供する）

Callingフレームワーク

　プログラムの主動権がフレームワーク側にあります。「Framework is Calling Your Program」の関係です。フレームワークは全体の流れを準備するので、その中で必要な部分を書き換えて行ったり、足りない部分をプログラマが造りこんでいくって感じです。いわゆるJ2EE フレームワークやStrutsなどのラッパーフレームワークがこれにあたります。全体の流れはフレームワーク側で規定しているので、プログラマが勝手にフレームワークの機能を呼び出すことはできません。

例：
- サーブレット（サーブレットを拡張して、POSTだのGETだのといったHTTPメソッドを書き換えていく）
- Struts、Wicket、Click Framework・・・
- DIコンテナ（Seasar、Spring Framework・・・）

　アプリケーション全体としてはプログラマの作ったコードはフレームワークから適宜呼ばれるってスタイルになります。フレームワークを使わないまでもTemplate method patternを使ってアプリケーションを構築したことのある方はこの感覚が分かると思います。この感覚を端的に表しているのが次の言葉で、自分もよく引用します。

Do not call me! I Call You!

　これは、よくよく調べたら「ハリウッドの原則（Hollywood Principle）」と呼ばれるものからの転用だそうです。その昔ハリウッドでは映画プロデューサーと俳優の関係は、まさに「オレ（プロデューサー）を呼ぶな！オレが電話する」という感じで、俳優側には映画の役などについて打診をするのはタブーだったそうで、主導権はプロデューサーにあったそうです。その言葉とフレームワークの関係が似ているということで、よく引用されるようになったとの事です。

　この「主動権がフレームワーク側にある」という感覚は自分で言うとDOS以前のプログラミングとWindowsのプログラミングの変遷に似ていて、DOS以前のプログラムはどちらかと言うとプログラマが流れの全体を作っていたのに対し、Windowsではイベントドリブンというプログラミングスタイルになり、プログラムの制御権がWindowsに移った中でイベントを肉付けしていくという、考え方を180度転換させられたのを思い出します。制御権が逆に移っている感覚がつかめなかったときは、当時はワケもわからず、このWindowsのmainの処理はどこなんだろう？？って考えていました。そんなの考えても無駄なのにね。

　この感覚については「制御の反転（Inversion of Control : IoC）」という言葉でRalph JohnsonとBrian Footeという方々が有名な論文を書いています。ちなみにRalph JohnsonはGoFの一人です。

　ん〜、まだ説明が難しいなぁ・・・

参考URL

制御の反転について

　このように，プログラムの制御がユーザー・コードから再利用コードのほうに移っている現象を，「制御の反転」（Inversion of Control，IoC）と呼びます。そして，「制御の反転」こそがフレームワークの本質であり，定義とさえ言えます。
http://itpro.nikkeibp.co.jp/article/lecture/20070205/260697/

制御の反転について（その２）
Designing Reusable Classes(Ralph E. Johnson & Brian Foote )

inversion of control gives frameworks the power to serve as extensible skeletons. The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application

・・・うーん、よ、読めん！

ハリウッドの原則について