多くのC++ライブラリやフレームワークが利用可能であり、それらを使用するとプロジェクト開発を加速できます。この記事では、C++アプリケーションが外部フレームワークに強く依存することの欠点を見ていきます。ただしその前に、ライブラリとフレームワークの違いは何でしょうか。また、なぜフレームワークへの強い結合は、ライブラリへの強い結合よりも多くの欠点をもたらす可能性があるのでしょうか？
両者の興味深い比較が、こちらの 記事：
The key difference between a library and a framework is "Inversion of Control". When you call a method from a library, you are in control. But with a framework, the control is inverted: the framework calls you.フレームワークは次のようにも定義できます：
It defines a skeleton where the application defines its own features to fill out the skeleton. In this way, your code will be called by the framework when appropriately. The benefit is that developers do not need to worry about if a design is good or not, but just about implementing domain specific functions.要約すると、フレームワークはライブラリよりも侵入的であり、アプリケーションのアーキテクチャや設計に影響を与える可能性があります。
たとえば、QtとMFCはよく知られた2つのC++フレームワークです。それぞれのWebサイトによる定義は次のとおりです：
Qt：
Qt is a cross-platform development フレームワーク enabling your team to deploy a single codebase providing common APIs across all supported platforms.そしてMFC：
Your work with the Microsoft Foundation Class (MFC) Library フレームワーク is based largely on a few major classes and several Visual C++ tools. Some classes encapsulate a large portion of the Win32 application programming interface (API). Other classes encapsulate application concepts such as documents, views, and the application itself. Still others encapsulate OLE features and ODBC and DAO data-access functionality.フレームワークはより侵入的です。アプリケーションがフレームワークと強く結合している場合、プロジェクトのほぼすべての関係者が影響を受けます。
採用担当者： プロジェクトが外部フレームワークと強く結合している場合、ほぼすべての開発者がそのフレームワークを習得している必要があり、プロジェクト向けの新しい開発者の採用が難しくなります。実際、使用しているフレームワークの経験をすでに持つC++開発者を探さなければならないからです。
アーキテクトとデザイナー： プロジェクトが外部フレームワークと強く結合している場合、柔軟性が失われ、プロジェクトの進化、移行、適応がすべてより複雑になります。
開発者： すべてのフレームワークには固有の複雑さがあり、プロジェクトと強く結合している場合、各開発者がそれを習得する必要があります。これによりプロジェクトの複雑さが増し、開発時間と品質に大きな影響を与える可能性があります。
テスト担当者： フレームワークと強く結合しているコードを分離してテストするのは非常に困難です。テスト担当者は、アプリケーションをテストするために追加作業を行わなければならないことがあります。
外部フレームワークを使用すると、プロジェクト開発を加速できます。しかし、慎重に使用し、不要な結合を可能な限り避ける必要があります。
いくつかのオープンソースC++プロジェクトを分析し、開発チームに参加するために開発者へ求められるスキルを見てみましょう。
ケース1：eMuleプロジェクト（http://www.emule-project.net）
eMuleプロジェクトをCppDependで分析すると、主にMFCフレームワークとWindows APIが使用されていることが分かります。
プロジェクトがMFCと強く結合しているかどうかを確認しましょう。そのために、どのメソッドがMFCを使用しているかをCppDependへ問い合わせます。 ツリーマップ グラフでの結果は次のとおりです：
ほぼすべてのメソッドがMFCフレームワークを使用しており、eMuleコードベースがMFCと強く結合していることが分かります。
最もよく使用されているMFCクラスを検索することもできます：
MFCはプロジェクト全体で使用されており、GUI、Internet、Archive、Containerの各クラスが使われています。
この強い結合には、2つの大きな欠点があります：
- eMuleのアルゴリズムを他のプロジェクトで簡単に再利用できません。再利用するにはMFCライブラリも使用しなければなりません。
- eMuleプロジェクトに参加したい開発者は、MFCライブラリを習得している必要があります。
ケース2：OpenSTAプロジェクト（http://sourceforge.net/projects/opensta/）
OpenSTAは複数のプロジェクトに分割されています。そのプロジェクト依存関係の一部は次のとおりです：
プロジェクトを複数のモジュールに分割することには大きな利点があります。機能を分離すると、他のプロジェクトで再利用しやすくなり、プロジェクトの複雑さも軽減されます。
どのプロジェクトがMFCを使用しているでしょうか？
すべてのプロジェクトがMFCフレームワークを使用しているわけではなく、最も大きなプロジェクトでは使用されていないことが分かります。
どのMFCクラスが使用されているでしょうか？
OpenSTAでは主にOLEクラスが使用されています。
MFCフレームワークのエキスパートではないC++開発者でも、多くのモジュールがMFCを直接使用していないため、OpenSTAチームへ参加できます。
概要
外部フレームワークの使用を分離することは、プロジェクトのすべての関係者にとって大きな利点があります。シンプルに保ち、特にビジネスレイヤーでは不要な結合を避けるようにしてください。