framework)とは、プログラミングにおいて、アプリケーションプログラム等に必要な一般的な機能が、あらかじめ別に実装されたものである。使い方としては、クラスライブラリとして実装されている場合は、継承したクラスを作ってユーザーが選択的に上書きしたり特化させたりする(一例であって、他にもさまざまな形態がある)。文脈から明確な場合は単に「フレームワーク」としたり、「アプリケーションフレームワーク」など前や後に別の語をつなげた複合語も多い。ソフトウェアフレームワークは、はっきり定義されたAPIを持ち、具体的な実装を再利用可能な形で隠蔽しているという点でライブラリとよく似ており、両者の間に明確な境界は無いし、分類のための明確な基準も無い。観点のひとつとしては、いわゆる「メインループ」あるいは「イベントループ」をアプリケーション側が持つか否か、という分類がある。メインループをアプリケーション側が持っていてそこから呼び出される形態のものがライブラリであり、一方フレームワークではメインループはフレームワーク側にあり、アプリケーションはそちら側から呼ばれるイベントハンドラによって駆動される(これについて「制御の反転」という語で説明されることがある[1])。この分類は、両者を特徴づけるはっきりした分類というわけではない。main関数はランタイムライブラリ中のスタートアップルーチンから呼び出される。広く使われているようなフレームワークでは、たいていはメインループをアプリケーション側が持つことができるようなメカニズムが用意されている。外部リンク背景と批判[編集]ソフトウェアフレームワークは、システム構築に必須な標準的かつ低レベルの詳細を設計者やプログラマが検討する時間を省き、要求仕様の実現に多くの時間を割けるようにし、ソフトウェア開発を容易にすることを目指している[2]。銀行のWebサイト構築にWebアプリケーションフレームワークを使っている開発チームは、要求処理や状態管理の機構を検討する時間を削減して、口座からの引き落としといった操作に注力できる。批判としては、フレームワークはコードを肥大化させるという主張もある。これは複数のフレームワークで競合する部分や補い合う部分があり、APIも複雑に絡み合っているためでもある。フレームワークの使い方を学ぶ時間がかかるという主張もある。一度フレームワークを学べば、同じフレームワークであれば、次のプロジェクトからはより素早く完璧な応用が可能となる。フレームワークは他のプラットフォーム製品(オペレーティングシステム、DBMSなど)と同様に、特定のフレームワーク・ベンダーや、特定のバージョンに依存(ロックイン)されるリスクがあるとの主張もある。このため機能内容や代替製品などの確認も必要である。いずれにしても、適切なフレームワークの選定は特に重要である。開発途中で、選択したフレームワークが開発要件を満たさないと判明した場合や、そのフレームワークの開発・提供が打ち切られた場合などは、開発途中で別のフレームワークに移行して(場合によっては基本設計から)再開発する必要が発生するためである。例[編集]ユーザーアプリケーションを立ち上げるのを助けるため、ソフトウェアフレームワークには一般にかなりの雑多なコードやユーティリティコードが含まれているが、全体としては特定の問題領域に注目した機能を提供している。