フレームワークとライブラリの違いは何ですか？[閉まっている]

フレームワークとライブラリの違いは何ですか？

私は常に、ライブラリーを、特定の問題またはアプリケーション開発の特定の領域（データベースアクセスなど）の解決に焦点を合わせたオブジェクトと関数のセットと考えていました。一方、フレームワークは、特定の方法論（つまりMVC）を中心とし、アプリケーション開発のすべての領域をカバーするライブラリーのコレクションです。

実際、これらの用語は、それらが使用されるコンテキストに応じて、さまざまなことを意味します。

たとえば、Mac OS Xでは、フレームワークは単なるライブラリであり、バンドルにパックされています。バンドル内には、実際の動的ライブラリー（libWhatever.dylib）があります。ベアライブラリとMacのフレームワークの違いは、フレームワークに複数の異なるバージョンのライブラリを含めることができることです。追加のリソース（画像、ローカライズされた文字列、XMLデータファイル、UIオブジェクトなど）を含めることができ、フレームワークが公開されない限り、通常、ライブラリを使用するために必要な.hファイルが含まれます。

したがって、アプリケーションのライブラリを使用するために必要なすべてのものが1つのパッケージ内にあります（.hファイルのないC / C ++ / Objective-Cライブラリは、ライブラリのドキュメントに従って自分で記述しない限り、ほとんど役に立ちません）。移動するファイルの束（MacバンドルはUnixレベルの単なるディレクトリですが、UIはそれを単一のファイルのように扱います。JavaにJARファイルがあるのと同じように、クリックしても通常は表示されません。コンテンツを表示することを明示的に選択しない限り、中身は何ですか）。

ウィキペディアはフレームワークを「流行語」と呼んでいます。ソフトウェアフレームワークを次のように定義します。

ソフトウェアフレームワークは、ソフトウェアシステム（またはサブシステム）の再利用可能な設計です。ソフトウェアフレームワークには、サポートプロジェクト、コードライブラリ、スクリプト言語、またはソフトウェアプロジェクトのさまざまなコンポーネントの開発と接着を支援するその他のソフトウェアが含まれる場合があります。フレームワークのさまざまな部分がAPIを通じて公開される場合があります。

だから私は図書館とはまさに「図書館」だと思います。これは、オブジェクト/関数/メソッド（言語によって異なります）のコレクションであり、アプリケーションはそれに「リンク」しているため、オブジェクト/関数/メソッドを使用できます。これは基本的に、通常複数のアプリケーションで共有できる再利用可能なコードを含むファイルです（同じコードを何度も何度も書く必要はありません）。

フレームワークは、アプリケーション開発で使用するすべてのものにすることができます。ライブラリ、多数のライブラリのコレクション、スクリプトのコレクション、またはアプリケーションを作成するために必要なソフトウェアの一部を使用できます。フレームワークは非常にあいまいな用語です。

これは、「ライブラリ対フレームワーク」というトピックに関するある人に関する記事です。私は個人的にこの記事は非常に議論の余地があると思います。彼がそこで言っていることは間違いではありませんが、彼はフレームワークの複数の定義の1つを選び、それをライブラリの古典的な定義と比較しているだけです。たとえば、サブクラス化のためのフレームワークが必要だと彼は言います。本当に？ライブラリでオブジェクトを定義したり、オブジェクトをリンクしたり、コードでサブクラス化したりできます。そのための「フレームワーク」がどのように必要かはわかりません。ある意味で、彼はむしろフレームワークという用語が今日どのように使用されているかを説明しています。前に言ったように、それは単なる誇大宣伝の言葉です。一部の企業は、通常のライブラリ（クラシックライブラリの任意の意味で）のみをリリースし、それを「フレームワーク」と呼んでいます。

ライブラリーを行い、特定の、明確に定義された操作。

フレームワークは、アプリケーションの骨格を記入して操作の「肉」を定義するスケルトンです。スケルトンにはパーツをリンクするコードがまだありますが、最も重要な作業はアプリケーションによって行われます。

ライブラリの例：ネットワークプロトコル、圧縮、画像操作、文字列ユーティリティ、正規表現評価、数学。操作は自己完結型です。

フレームワークの例： Webアプリケーションシステム、プラグインマネージャー、GUIシステム。フレームワークは概念を定義しますが、アプリケーションはエンドユーザーが気にする基本的な機能を定義します。

主な違いは、フレームワークが「ハリウッドの原則」に従うということだと思います。つまり、「私たちを呼ばないでください。私たちはあなたを呼びます」

よると、Martin Fowler氏：

ライブラリは、基本的にあなたが呼び出すことができるという機能のセットで、これらの日は、通常のクラスに編成します。各呼び出しはいくつかの作業を行い、クライアントに制御を返します。

フレームワークは、内蔵のより行動で、いくつかの抽象的デザインを具現化している。それを使用するためには、サブクラス化するか、独自のクラスに差し込むことにより、いずれかの枠組みの中でのさまざまな場所にあなたの行動を挿入する必要があります。フレームワークのコードは、これらのポイントでコードを呼び出します。

ライブラリを呼び出します。

フレームワークはあなたを呼び出します。

図書館助け
足場が痛い多く
の涙

図書館：

これは、単なるルーチン（関数型プログラミング）またはクラス定義（オブジェクト指向プログラミング）のコレクションです。背後にある理由は、単にコードを再利用することです。つまり、他の開発者がすでに作成したコードを取得します。クラスまたはルーチンは、通常、ドメイン固有の領域で特定の操作を定義します。たとえば、アルゴリズムの機能の実装をやり直すことなく、開発者が関数を呼び出すだけの数学ライブラリがあります。

フレームワーク：

フレームワークでは、すべての制御フローがすでに存在しており、コードで記入する必要のある定義済みの白いスポットがたくさんあります。フレームワークは通常、より複雑です。これは、スケルトンを定義するアプリケーションが独自の機能を定義するスケルトンを定義します。このようにして、適切なときにフレームワークによってコードが呼び出されます。利点は、開発者がデザインの良し悪しを気にする必要がなく、ドメイン固有の機能を実装することだけです。

ライブラリ、フレームワーク、およびコードイメージ表現：

KeyDifference：

ライブラリとフレームワークの主な違いは、「制御の反転」です。ライブラリからメソッドを呼び出すときは、自分で制御できます。しかし、フレームワークでは、コントロールが逆になります。フレームワークはあなたを呼び出します。ソース。

関係：

どちらもプログラマーが使用するAPIを定義しています。これらをまとめると、ライブラリはアプリケーションの特定の機能、フレームワークはアプリケーションのスケルトンと考えることができます。APIはそれらをまとめるためのコネクタです。典型的な開発プロセスは通常、フレームワークから始まり、APIを通じてライブラリで定義された関数に入力します。

私はいつもそれを説明したので：

ライブラリはツールです。

フレームワークは生き方です。

どんな小さなパーツでも役立つライブラリを使用できます。プロジェクト全体をコミットする必要があるフレームワーク。

Web開発者の観点から：

1. ライブラリは別のライブラリと簡単に交換できます。しかし、フレームワークはできません。

   jquery日付ピッカーライブラリが気に入らない場合は、ブートストラップ日付ピッカーやpickadateなどの他の日付ピッカーに置き換えることができます。

   製品を構築したAngularJSが気に入らない場合は、他のフレームワークに置き換えることはできません。コードベース全体を書き直す必要があります。

2. ほとんどの場合、ライブラリはフレームワークに比べて学習曲線が非常に短くなります。例：underscore.jsはライブラリ、Ember.jsはフレームワークです。

私はコーエンスの答えが好きですが、より技術的な定義は次のとおりです。コードがライブラリを呼び出します。フレームワークがコードを呼び出します。たとえば、GUIフレームワークは、イベントハンドラーを介してコードを呼び出します。Webフレームワークは、いくつかの要求応答モデルを通じてコードを呼び出します。

これは、制御の逆転とも呼ばれます。突然、フレームワークは、ライブラリの場合とは逆に、コードを実行するタイミングと方法を決定します。つまり、フレームワークは、コードの構造化方法にも大きな影響を与えます。

この定義を見た場所を忘れてしまいましたが、とてもいいと思います。

ライブラリはコードから呼び出すモジュールであり、フレームワークはコードを呼び出すモジュールです。

フレームワークは、さまざまなライブラリから作成できます。例を見てみましょう。

魚のカレーを作りたいとしましょう。次に、油、スパイス、その他の成分が必要ですユーティリティの。また、料理を作るためのベースとなる魚も必要です（これはアプリケーションのデータです）。フレームワークと呼ばれるすべての成分。次に、これらを1つずつまたは組み合わせて使用​​して、最終製品であるフィッシュカレーを作ります。これを、underscore.js、bootstrap.css、bootstrap.js、fontawesome、AngularJSなどで作成されたWebフレームワークと比較してください。例として、 TwitterのブートストラップV.35

今、あなたが言うように1つの成分だけを考えれば、オイル。それはあなたの魚（データ）を台無しにするので、あなたはあなたが望むどんな油も使うことができません。オリーブオイルのみ使用できます。それをunderscore.jsと比較してください。使用したいオイルのブランドはあなた次第です。アメリカのオリーブオイル（underscore.js）またはインドのオリーブオイル（lodash.js）で作られた料理がいくつかあります。これはあなたのアプリケーションの味を変えるだけです。それらはほとんど同じ目的を果たすので、それらの使用は開発者の好みに依存し、簡単に交換できます。

フレームワーク：アプリケーションに固有のプロパティと動作を提供するライブラリのコレクション。（全成分）

ライブラリ：データに固有のプロパティと動作を提供する明確に定義された一連の命令。（魚の油）

プラグイン：ライブラリー（ui-router-> AngularJS）または多くのライブラリーの組み合わせ（date-picker-> bootstrap.css + jQuery）用のユーティリティビルド。プラグインなしでは、プラグインは期待どおりに機能しない可能性があります。

PS AngularJSはMVCフレームワークですが、JavaScriptライブラリです。ライブラリはネイティブテクノロジー（この場合はJavaScript）のデフォルトの動作を拡張していると思います。

これは私がそれをどう思うか（そして他の人たちによって合理化されているのを見てきました）：

ライブラリは、コード内に含まれるものです。また、フレームワークはアプリケーションのコンテナです。

ここにはJoel Spolskyによる苦い記事がリンクされていますが、ツールボックス、ライブラリ、フレームワークなどの明確な区別が含まれています

ライブラリは、狭い範囲の目的で機能を実装しますが、フレームワークは、幅広い機能をサポートするライブラリのコレクションである傾向があります。たとえば、ライブラリSystem.Drawing.dllは描画機能を処理しますが、.NETフレームワーク全体の一部にすぎません。

ライブラリ-クライアントが特定のタスクを実行するのに適していると見なすときに使用できるクラスまたはコンポーネントのセット。
フレームワーク-あなたよりも大きな何かに「プラグイン」するための特定のガイドラインを義務付けます。「フレームワークがあなたの人生を楽にすることができるように」、あなたはアプリケーション/要件に固有の部分を公開された必要な方法で提供するだけです

ライブラリは、使いやすさと効率性を目的としています。たとえば、Zendライブラリは、明確に定義されたクラスと関数を使用してさまざまなタスクを実行するのに役立ちます。フレームワークは、通常、MVC（Model -view-controller）（リファレンス）。MVCのようにタスクを分散するための明確に定義されたシステムです。モデルにはデータベース側が含まれ、ビューはUIインターフェース用、コントローラーはビジネスロジック用です。

あなたの解釈は私にはかなりいいですね... ライブラリは、他のコードで再利用するためにコンパイルされて自己完結しているものであれば何でも構いません。その内容には文字通りの制限はありません。

フレームワーク一方では、ちょうどあなたの例では、MVCのように、アプリケーション開発のいくつかの特定の分野での使用のための施設の範囲を持つことが期待されています。

フレームワークは私たちの作業を行うフレームを提供します...どういうわけか、それは単純なライブラリーよりも「制約的」です。
フレームワークは、一連のライブラリに一貫性を追加することも想定されています。

ライブラリは、目標を達成するためのユーティリティのセット（たとえば、ソケット、暗号化など）だと思います。フレームワークはライブラリ+ランタイムEINVIRONNEMENTです。たとえば、ASP.NETはフレームワークです。HTTPリクエストを受け入れ、ページオブジェクトを作成し、lyfe cicleイベントを呼び出します。フレームワークはすべてこれを行います。あなたは、現在のリクエスト！

とにかく、非常に興味深い質問です！

この回答の出所は覚えていません（インターネットの.pptで見つけたと思います）が、答えは非常に簡単です。

ライブラリとフレームワークは、アプリケーションで使用でき、特定の「問題」を解決するのに役立つクラス、モジュール、コード（プログラミング言語に依存）のセットです。

その問題は、アプリケーションのログまたはデバッグ情報、グラフの描画、特定のファイル形式（html、pdf、xls）の作成、データベースへの接続、アプリケーションの一部または完全なアプリケーションの作成、またはデザインパターン。

これらのすべての問題を解決するためにフレームワークまたはライブラリを使用できますが、通常、フレームワークはより複雑なまたはより大きな問題を解決するのに役立ちますが、両方の主要な定義ではなく、それらの主な違いの継承です。

ライブラリとフレームワークの主な違いは、独自のコード間の依存関係です。つまり、フレームワークを使用するには、FWでほとんどすべてのクラス、モジュール、またはコードを使用する必要がありますが、ライブラリを使用するには、独自のアプリケーションのlib内のいくつかのクラス、モジュール、またはコード

つまり、使用する必要があるアプリでフレームワークを使用するために、フレームワークに50のクラスがある場合、たとえば、コードで10〜15以上のクラスを使用するとします。クラス（そのクラスのオブジェクト）は、フレームワークの他のクラスのメソッドの入力/パラメーターです。.NETフレームワーク、Spring、またはその他のMVCフレームワークを参照してください。

しかし、たとえばログライブラリの場合、コードでLogクラスを使用するだけで、「ログの問題」を解決するのに役立ちます。これは、ログライブラリのコード内にクラスなどのクラスがないことを意味するわけではありませんファイルを処理したり、画面出力を処理したり、データベースを処理したりすることはできますが、コード内でそのクラスに触れたり使用したりすることは決してありません。それが、フレームワークではなくライブラリである理由です。

また、フレームワークやライブラリよりも多くのカテゴリがありますが、それはトピック外です。