フレームワークとライブラリの違いは何ですか?
私は常にライブラリを、特定の問題やアプリケーション開発の特定の領域 (データベース アクセスなど) の解決に焦点を当てたオブジェクトと関数のセットと考えていました。一方、フレームワークは、特定の方法論 (つまり MVC) を中心としたライブラリのコレクションであり、アプリケーション開発のすべての領域をカバーします。
フレームワークとライブラリの違いは何ですか?
私は常にライブラリを、特定の問題やアプリケーション開発の特定の領域 (データベース アクセスなど) の解決に焦点を当てたオブジェクトと関数のセットと考えていました。一方、フレームワークは、特定の方法論 (つまり MVC) を中心としたライブラリのコレクションであり、アプリケーション開発のすべての領域をカバーします。
ライブラリは、明確に定義された特定の操作を実行します。
フレームワークは、アプリケーションがスケルトンに記入することによって操作の「肉」を定義するスケルトンです。スケルトンにはパーツをリンクするコードがまだありますが、最も重要な作業はアプリケーションによって行われます。
ライブラリの例:ネットワーク プロトコル、圧縮、画像操作、文字列ユーティリティ、正規表現の評価、数学。操作は自己完結型です。
フレームワークの例: Web アプリケーション システム、プラグイン マネージャー、GUI システム。フレームワークは概念を定義しますが、アプリケーションはエンドユーザーが関心を持つ基本的な機能を定義します。
実際、これらの用語は、使用されるコンテキストに応じて、さまざまな意味を持ちます。
たとえば、Mac OS X のフレームワークは、バンドルにパックされた単なるライブラリです。バンドル内には、実際の動的ライブラリ (libWhatever.dylib) があります。ベア ライブラリと Mac のフレームワークの違いは、フレームワークには複数の異なるバージョンのライブラリを含めることができることです。追加のリソース (画像、ローカライズされた文字列、XML データ ファイル、UI オブジェクトなど) を含めることができ、フレームワークが公開されていない限り、通常はライブラリを使用するために必要な .h ファイルが含まれています。
したがって、アプリケーションでライブラリを使用するために必要なすべてが 1 つのパッケージ内に含まれています (.h ファイルのない C/C++/Objective-C ライブラリは、ライブラリのドキュメントに従って自分で作成しない限り、ほとんど役に立ちません)。移動するファイルの束 (Mac バンドルは Unix レベルのディレクトリにすぎませんが、UI はそれを 1 つのファイルのように扱います。Java に JAR ファイルがあるのとほとんど同じで、クリックしても通常は表示されません。コンテンツを表示するように明示的に選択しない限り、中身は何ですか)。
ウィキペディアはフレームワークを「流行語」と呼んでいます。ソフトウェアフレームワークを次のように定義します
ソフトウェア フレームワークは、ソフトウェア システム (またはサブシステム) の再利用可能な設計です。ソフトウェア フレームワークには、サポート プログラム、コード ライブラリ、スクリプト言語、またはソフトウェア プロジェクトのさまざまなコンポーネントの開発と結合を支援するその他のソフトウェアが含まれる場合があります。フレームワークのさまざまな部分は、API を通じて公開できます。
だから、図書館はまさに「図書館」だと思います。オブジェクト/関数/メソッド (言語によって異なります) のコレクションであり、アプリケーションはそれに対して「リンク」するため、オブジェクト/関数/メソッドを使用できます。これは基本的に、再利用可能なコードを含むファイルであり、通常は複数のアプリケーション間で共有できます (同じコードを何度も書く必要はありません)。
フレームワークは、アプリケーション開発で使用するすべてのものにすることができます。これは、ライブラリ、多くのライブラリのコレクション、スクリプトのコレクション、またはアプリケーションの作成に必要なソフトウェアの一部である可能性があります。フレームワークは非常にあいまいな用語です。
これは、「ライブラリとフレームワーク」というトピックに関するある人の記事です。個人的にはこの記事は賛否両論あると思います。彼がそこで言っていることは間違っていませんが、フレームワークの複数の定義の 1 つを選び出し、それをライブラリの古典的な定義と比較しているだけです。たとえば、サブクラス化のためのフレームワークが必要だと彼は言います。本当に?ライブラリでオブジェクトを定義し、それに対してリンクし、コードでサブクラス化できます。そのための「フレームワーク」がどのように必要かわかりません。彼はフレームワークという用語が現在どのように使われているかを説明しています。前に言ったように、それは誇張された言葉です。一部の企業は、通常のライブラリ (あらゆる意味での古典的なライブラリ) だけをリリースし、それを「フレームワーク」と呼んでいます。
主な違いは、フレームワークが「ハリウッドの原則」、つまり「私たちに電話しないで、あなたに電話します」に従うことだと思います。
マーティン・ファウラーによると:
ライブラリは基本的に、呼び出すことができる関数のセットであり、最近では通常クラスに編成されています。各呼び出しは何らかの作業を行い、制御をクライアントに返します。
フレームワークは、より多くの動作が組み込まれた、いくつかの抽象的な設計を具現化します。これを使用するには、サブクラス化するか、独自のクラスをプラグインして、フレームワークのさまざまな場所に動作を挿入する必要があります。フレームワークのコードは、これらのポイントでコードを呼び出します。
ライブラリを呼び出します。
フレームワークがあなたを呼び出します。
図書館助け
足場が痛い<br> 対抗の涙
私がいつも説明してきたように:
ライブラリはツールです。
フレームワークは生き方です。
どんな小さな部分でも役立つライブラリです。プロジェクト全体をコミットする必要があるフレームワーク。
Web 開発者の観点から:
ライブラリは、別のライブラリに簡単に置き換えることができます。しかし、フレームワークはできません。
jquery 日付ピッカー ライブラリが気に入らない場合は、bootstrap 日付ピッカーや pickadate などの他の日付ピッカーに置き換えることができます。
製品を構築した AngularJS が気に入らない場合は、他のフレームワークに置き換えることはできません。コードベース全体を書き直す必要があります。
ほとんどのライブラリは、フレームワークに比べて習得に時間がかかりません。例: underscore.js はライブラリ、Ember.js はフレームワークです。
私はCohensの答えが好きですが、より技術的な定義は次のとおりです。コードはライブラリを呼び出します。フレームワークがコードを呼び出します。たとえば、GUI フレームワークはイベント ハンドラを介してコードを呼び出します。Web フレームワークは、何らかの要求応答モデルを通じてコードを呼び出します。
これは、制御の反転とも呼ばれます。ライブラリの場合のようにコードを実行するタイミングと方法をフレームワークが決定するのではなく、フレームワークが突然決定します。これは、フレームワークが、コードをどのように構造化する必要があるかについて、はるかに大きな影響を与えることも意味します。
この定義をどこで見たか忘れましたが、かなりいいと思います。
ライブラリはコードから呼び出すモジュールであり、フレームワークはコードを呼び出すモジュールです。
フレームワークは、さまざまなライブラリから作成できます。例を見てみましょう。
魚のカレーを作りたいとしましょう。次に、油、スパイス、その他のユーティリティなどの材料が必要です。また、料理を作るベースとなる魚も必要です(これはアプリケーションのデータです)。すべての構成要素をまとめてフレームワークと呼びます。これで、それらを 1 つずつ、または組み合わせて使用して、最終製品であるフィッシュ カレーを作ることができます。underscore.js、bootstrap.css、bootstrap.js、fontawesome、AngularJSなどから作成されたWeb フレームワークと比較してください。例として、Twitter Bootstrap v.35.
ここで、油などの 1 つの成分だけを考えてみます。魚(データ)が台無しになるため、必要なオイルを使用することはできません。オリーブオイルのみ使用できます。それをunderscore.jsと比較してください。どのブランドのオイルを使用するかはあなた次第です。一部の料理は、アメリカン オリーブ オイル(underscore.js) またはインド オリーブ オイル(lodash.js) で作られました。これは、アプリケーションの好みを変えるだけです。これらはほぼ同じ目的を果たすため、用途は開発者の好みに依存し、簡単に交換できます。
Framework : アプリケーションに固有のプロパティと動作を提供するライブラリのコレクション。(全成分)
ライブラリ: データに固有のプロパティと動作を提供する明確に定義された一連の命令。(魚油)
Plugin : ライブラリ (ui-router -> AngularJS) または多くのライブラリの組み合わせ (date-picker -> bootstrap.css + jQuery) のユーティリティ ビルドで、これがなくてもプラグインが期待どおりに動作する可能性があります。
PS AngularJS は MVC フレームワークですが、JavaScript ライブラリです。Library はネイティブ テクノロジ (この場合は JavaScript) のデフォルトの動作を拡張すると考えているためです。
これは私が考える方法です(そして他の人によって合理化されているのを見てきました):
ライブラリは、コード内に含まれるものです。フレームワークはアプリケーションのコンテナです。
here はJoel Spolsky による苦い記事にリンクされていますが、ツールボックス、ライブラリ、フレームワークなどの明確な区別が含まれています
少し前にあなたの街にハンバーガーレストランをオープンしたとしましょう。しかし、初心者としてハンバーガーを作るのはとても難しいと感じています. あなたは顧客のためにハンバーガーを作る簡単な方法を考えていました。フレームワークを使えばバガーが簡単に作れるって誰かが言ってた。McDonald Burger FrameworkとBurgerKing Burger Frameworkがあることを知りました。
McDonald Burger Frameworkを使えば、 Big Macバーガーがとても簡単に作れます。(ただし、Whopper は作成できません。)
BurgerKing Burger Frameworkを使えば、 Whopper Burgerがとても簡単に作れます。(ただしビッグマックは作れません)
とにかく、結局、すべてハンバーガーです。ここで重要なことは、ハンバーガーを作るためにフレームワークのルールに従わなければならないということです. そうしないと、それを作るのがさらに難しく感じるか、それを作ることができなくなります.
また、 Simple Burger-Patty Libraryというものがあると聞きました。
このライブラリを使えば、どんなバーガーパティも簡単に作ることができます(倍速)。McDonald Burger Framework を使用するか、BurgerKing Burger Framework を使用するかは問題ではありません。いずれにせよ、このSimple Burger-Patty Libraryは引き続き使用できます。(このライブラリは、フレームワークなしでも使用できます。)
フレームワークとライブラリの違いがわかりますか?
McDonald Burger Frameworkを使い始めたら。BurgerKing Burger Frameworkに切り替えるのは簡単ではありません。キッチン全体を交換する必要があるためです。
しかし、ライブラリ、他のものを切り替える方がはるかに簡単です. または、使用しないこともできます。
ライブラリは狭い範囲の目的のために機能を実装しますが、フレームワークはより広い範囲の機能をサポートするライブラリのコレクションになる傾向があります。たとえば、ライブラリ System.Drawing.dll は描画機能を処理しますが、.NET フレームワーク全体の一部にすぎません。
ライブラリは、目標を達成するためのユーティリティのセットだと思います(たとえば、ソケット、暗号化など)。フレームワークはライブラリ + RUNTIME EINVIRONNEMENT です。たとえば、ASP.NET はフレームワークです。HTTP 要求を受け入れ、ページ オブジェクトを作成し、lyfe cicle イベントを呼び出します。フレームワークはこれらすべてを行います。現在のリクエスト!
とにかく、非常に興味深い質問です!
この回答の出典は覚えていませんが(インターネットの.pptで見つけたと思います)、回答は非常に簡単です。
ライブラリとフレームワークは、アプリケーションで使用できるクラス、モジュール、コード(プログラミング言語によって異なります)のセットであり、特定の「問題」を解決するのに役立ちます。
その問題は、アプリケーションのログまたはデバッグ情報、チャートの描画、特定のファイル形式(html、pdf、xls)の作成、データベースへの接続、アプリケーションの一部または完全なアプリケーションの作成、またはに適用されるコードである可能性があります。デザインパターン。
フレームワークまたはライブラリを使用してこれらすべての問題を解決できます。通常、フレームワークはより複雑またはより大きな問題を解決するのに役立ちますが、両方の主な定義ではなく、主な違いの結果です。
ライブラリとフレームワークの主な違いは、独自のコード間の依存関係です。つまり、フレームワークを使用するには、FW内のほぼすべてのクラス、モジュール、またはコードを使用する必要がありますが、ライブラリを使用するには、1つまたは独自のアプリケーションのライブラリにあるいくつかのクラス、モジュール、またはコード
これは、たとえば、使用する必要のあるアプリでフレームワークを使用するためにフレームワークに50のクラスがある場合、コードに10〜15以上のクラスがあることを意味します。これは、フレームワークの設計方法であるためです。クラス(そのクラスのオブジェクト)は、フレームワーク内の他のクラスのメソッドの入力/パラメーターです。.NET Framework、Spring、または任意のMVCフレームワークを参照してください。
ただし、たとえばログライブラリの場合、コードでLogクラスを使用するだけで、「ログの問題」を解決できます。これは、ログライブラリのコードにクラスのようなクラスがないことを意味するわけではありません。ファイルを処理したり、画面出力を処理したり、データベースを処理したりしますが、コード内でそのクラスに触れたり使用したりすることはありません。これが、フレームワークではなくライブラリである理由です。
また、フレームワークやライブラリよりも多くのカテゴリがありますが、それはトピックから外れています。
あなたの解釈は私にはかなり良いように聞こえます...ライブラリは、他のコードで再利用するためにコンパイルされ、自己完結型のものであれば何でもかまいません。その内容に文字通り制限はありません。
一方、フレームワークには、MVCの例のように、アプリケーション開発の特定の分野で使用するためのさまざまな機能が期待されています。
フレームワークは、私たちが作業を行うためのフレームを提供します...どういうわけか、単純なライブラリよりも「制約」があります。
このフレームワークは、一連のライブラリに一貫性を追加することも想定されています。
ライブラリ - クライアントが特定のタスクを達成するのに適していると判断した場合に使用できるクラスまたはコンポーネントのセット。
フレームワーク - 自分よりも大きなものに「プラグイン」するための特定のガイドラインを義務付けています。「フレームワークはあなたの人生を楽にすることができる」ように、公開された必要な方法でアプリケーション/要件に固有の部分を提供するだけです
Erich Gamma らによる著書Design Patternsに記載されている定義に基づいています。
問題固有のコードは、ライブラリを使用してフレームワークを実装できます。