Many C++ libraries and frameworks are available, and using them can accelerate the development of your projects. In this post we will explore the drawbacks of having a C++ application that is highly dependent on an external framework. But first, what’s the difference between a library and a framework? And why can tight coupling to a framework have more drawbacks than tight coupling to a library?
Here’s an interesting comparison between them, from this post:
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.A framework can also be defined like this:
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.To summarize, a framework is more intrusive than a library, and it can influence your application architecture and design.
For example, Qt and MFC are two well-known C++ frameworks; here are their definitions from their websites:
Qt:
Qt is a cross-platform development framework enabling your team to deploy a single codebase providing common APIs across all supported platforms.And MFC:
Your work with the Microsoft Foundation Class (MFC) Library framework 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.A framework is more intrusive; if an application is highly coupled with it, almost all project stakeholders will be affected.
Recruiter: If a project is highly coupled with an external framework, almost every developer must master this framework, making it more difficult to recruit new developers for the project. Indeed, we have to look for C++ developers who already have experience with the framework being used.
Architect and designer: When the project is highly coupled with an external framework, we lose flexibility, and any evolution, migration, or adaptation of the project becomes more complicated.
Developer: Every framework has its own complexities, and when it is tightly coupled to the project, each developer needs to master it. This adds complexity to the project and can significantly affect development time and quality.
Tester: It’s very difficult to isolate and test our own code when it’s tightly coupled to a framework. Sometimes the tester needs to do some extra work to test the application.
Using an external framework can accelerate the development of a project. However, we must use it carefully and avoid unnecessary coupling as much as possible.
Let’s analyze some open-source C++ projects and see what skills a developer needs to join their development teams.
Case I: Emule project (http://www.emule-project.net)
After analyzing the eMule project with CppDepend, we observe that it mainly uses the MFC framework and the Windows API.
Let’s see if the project is highly coupled with MFC; to do that, we can ask CppDepend which methods use MFC. Here’s the result in the treemap graph:
We observe that almost all the methods use the MFC framework, which makes the eMule codebase highly coupled with it.
We can also search for the most used MFC classes:
MFC is used throughout the project: it uses the GUI, Internet, Archive, and Container classes.
This high coupling has two major drawbacks:
- We can’t easily reuse the eMule algorithms in other projects; we also have to use the MFC library if we want to reuse them.
- Any developer who wants to join the eMule project must master the MFC library.
Case II: OpenSTA project (http://sourceforge.net/projects/opensta/)
OpenSTA is divided into multiple projects; here are some of its project dependencies:
Dividing a project into multiple modules can be very advantageous: isolating functionality makes it easier to reuse in other projects and reduces the project’s complexity.
Which projects use MFC?
We observe that not all the projects use the MFC framework, and the largest ones do not use it.
Which MFC classes are used?
OpenSTA mainly uses the OLE classes.
A C++ developer who is not an expert in the MFC framework can still join the OpenSTA team because many modules do not use MFC directly.
Summary
Isolating the use of an external framework can be very advantageous for all project stakeholders; try to keep it simple and avoid any unnecessary coupling, especially with the business layer.