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

質問

こんにちわ。
Java(というか全般的に??)ではフレームワークが花盛りですが、フレームワークとクラスライブラリの明確な違いってなんでしょうか。

私個人としては以下のように解釈してます。
・フレームワークとは使う上でのメリットはあるが、規約を強制するもの。人が仕組みにあわせて設計・プログラミングする。
・ライブラリは使う上でのルール(使い方)はあるものの、人が好きなように使える便利ツール集。

ただこの観点でいくとO/Rマッピングなどは・・・？
作る側としてはライブラリは結構気軽に作っていけるものの、フレームワークは何よりも思想が大事なのかな、と思っています。

皆さんのご意見をお聞かせください。

回答No.5

arakororin

フレームワーク呼ばれることがあるものを列挙してみます
(1)部分的な機能(コレクションフレームワーク：List, Map, Set)
(2)O/Rマッパー(Hibernate)
(3)(一般的な)フレームワーク(Struts, Spring)
(4)プロジェクト毎独自作成の(自称)フレームワーク

基本的には作った人がフレームワークと呼びたいか、フレームワークのつもりで作ったかどうかで、フレームワークと呼ばれるかどうかが決まると思います。その意味では上記の全てがフレームワークです。

私の個人的な意見では、記述を劇的に変更させるほどの仕組みがフレームワークだと思います。もう少し詳しく言うと、記述を簡素にするだけなのは共通部品で、記述そのものをしなくてよくなるのがフレームワークといえると思います。

その意味で、コレクションフレームワークが提供された事により、配列の追加の際にnewして配列をつくり直す記述をしなくなってよくなった意義はきわめて大きく、これはフレームワークといえます。O/RマッパーもSQLを記述しなくてもよくなった点や、(一般的な)フレームワークでサーブレットを記述しなくてよくなったという観点から、両者はフレームワークといえます。

微妙なのはプロジェクト毎独自作成(自称)フレームワークで、これはただの機能を提供しているだけなのにフレームワークと呼ぶ場合があります。この中での切り分けは、例えばログを出力するメソッドを提供するだけというのはただの共通部品もしくはライブラリ、一方、BLやDAOのメソッドの呼び出しと終了時に自動的にログを出力する仕組みを提供するのがフレームワークだと思います。

>フレームワークのことを部品、部品と呼ぶ人たちがいますが
というのは、ただの共通部品にすぎないのにフレームワークと呼んでいるものがあるからなのではないかと思います。

結論としてNo.2さんの
>フレームワークとはある特定の処理を自動的に処理してくれる枠組みと考えてみてはどうでしょうか。
や、No.3さんの
>ライブラリは「機能」を提供するものであり、フレームワークは「仕組み」を提供するものである
と同じですね…。

思想や規約をフレームワークである程度規定することはできると思いますが、それはフレームワークの本来の役割ではないと思います。思想や規約はPJ毎に定めるコーディング規約に盛り込むべきだと思います。

回答No.4

kazsharp

仕事でフレームワークの設計をしました。

フレームワークとライブラリの違いはNo.3の方と同じ意見です。
「フレームワークは思想が大事」という点ですが、これはフレームワーク作成者としても悩みどころで、

「そのフレームワークを適用することで、どれくらい工数が削減できるの？」

と質問されたことがあり、その質問をした人は８０％程度をフレームワークで実装してて残り２０％の実装だけで済むというのを期待していたようですが

「８０％程度をフレームワークで実装してしまうとそのフレームワークはあまり汎用的には作られていないということだし、おおくのアプリケーションに適用できるような汎用的なフレームワークは１０％程度しか工数を削減できないかもしれない」

と説明したところ

「１０％の工数削減のために『フレームワーク作成』に何人もの人をアサインしてコストをかける価値があるのか？」

と言われました。

もちろん１つのプロジェクトだけに適用するとフレームワーク作成のほうがコストは大きいですが、いくつものプロジェクトに適用することでフレームワーク作成のコストは徐々に償却されていくはずです。

ただ、フレームワークの実装を（アプリケーション全体の）何％になるように設計するかというのはまさに思想レベルで、正解はないと思います。
実際、Strutsのように10％未満程度の工数削減にしかならないフレームワークでも使われまくったりしてますから。

回答No.3

noname#49664

フレームワークの定義で必ず登場するのが、「ハリウッド原則」というやつです。

「私を呼ばないで！　私があなたを呼ぶから」
（Don't call me! I will call you）

基本的に、「プログラマが自分で呼び出し使うもの」が普通のライブラリであるのに対し、フレームワークは、フレームワークのほうが必要に応じてプログラマの作ったプログラムを呼び出します。その点が一番大きな違いでしょう。ライブラリは「機能」を提供するものであり、フレームワークは「仕組み」を提供するものである、という認識は正しいと思います。

そういう点からいえば、ORMもフレームワークだと思いますよ。ただし、システム全体を構築するためのフレームワークではありませんから用途的には限定された形になります。それで、フレームワークっぽくない感じがするのでしょう。
　けれど、たとえばHibernateでは、データベースのデータをマッピングするためのクラスやマッピングファイルなどの定義をHibernateの指示に従って記述しておくと、必要に応じてそれらの情報やクラスが呼び出され適切な形にデータがマッピングされ返されます。プログラマが自分でマッピングファイルを読み込み、それをもとにデータベースから取得したデータをマッピングクラスのインスタンスとして変換する処理を呼び出しているわけではありません。となると、これは機能限定的ではあるけれど、れっきとしたフレームワークといってよいのではないでしょうか。

お礼

ハリウッド原則って私も聞いたことあります！

自分はフレームワーク≒コントローラってイメージですね。
あくまでも呼び出されるロジック、パーツをプログラムして、フレームワーク側には呼び出し方を設定ファイルで定義する、みたいな。
んで、フレームワークは定義された設定に従って処理を呼んでいくという。

それにしてもフレームワークの設定ファイルと記述内容の多さには軽く閉口気味です(-_-;)

回答No.2

haniue

よくフレームワークのことを部品、部品と呼ぶ人たちがいますが、ちょっと違う気がします。
フレームワークとはある特定の処理を自動的に処理してくれる枠組みと考えてみてはどうでしょうか。

わたしはよく、ＶＢの作成画面がフレームワークだと説明しています。
ボタンのクリックイベントに処理をコーディングするだけで、クリックされたらその処理が呼び出される・・・
つまり、フレームワークがその処理（呼び出す処理）を行っているのだと。

参考までに。

お礼

フレームワークを部品と呼ぶのは私は抵抗ありますね。どちらかというとライブラリの方が部品ぽいような・・・(^_^;)

VBですか、私は使ったことないのですがやはりフレームワークは自分で呼び出すのではなく呼び出されるといった感じですね

回答No.1

rinkun

フレームワーク・ライブラリという言い方もありますが(^-^;)

ライブラリは良く使うプログラム部品を集めたもの。
フレームワークはアプリケーションの枠組みですね。

オブジェクト指向以前では個別の機能部品はライブラリにできても枠組みをライブラリとして提供するのは難しかったのです。
オブジェクト指向でポリモフィズムを利用することにより枠組みをライブラリとして提供しやすくなりフレームワーク・ライブラリが作られるようになりました。

フレームワークは大きな部品なので「規約を強制」「思想が大事」と思うかもしれませんが、仕様を理解していないと正しく使えないという点ではライブラリもフレームワークも大差ないと思いますよ。

お礼

なるほど、フレームワークはオブジェクト指向の産物なのですね。
だから、Cではあまりフレームワークって単語を聞かなかったりするんですね。