Many C++ libraries and frameworks are available and using them can accelerate the development of your projects. In this post we will explore the drawback of having a C++ application highly dependent with an external framework. But first what’s the difference between a library and a framework? And why the high coupling with a framework could have more drawbacks than a high coupling with a library?
Here’s from this post an interesting comparison between them:
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.
And the framework could be defined like that:
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 resume the framework is more intrusive than a library and it could influence your application architecture and design.
For example Qt and MFC are two 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.
Because the framework is more intrusive. If an application is highly coupled with it, almost all the actors of the project will be impacted.
Human resource recruiter:
If a project is highly coupled with an external framework, almost each developer must master this framework which makes the task of recruiting new developers to integrate the project more difficult. Indeed, we must search for C++ developers who have some background about the framework used.
Architect and designer:
When the project is highly coupled with an external framework, we lose of flexibility, and any evolution, migration or adaptation of the project became more complicated.
Developer:
Any framework has its difficulties and force every developer to master it because it’s highly coupled with the project. It will add more complexity to the project and it will have a big impact on the development time and quality.
Tester:
It’s very difficult to isolate just our code and test it if it’s highly coupled with other frameworks. Sometimes the tester need to do some extra works to test the application.
It’s nice to use an external framework to accelerate the development of our project. However, we must use them carefully and avoid as possible unnecessary coupling.
Let’s analyze some C++ open source projects and discover what skills needed for a developer who want to integrate their development team.
Case I: Emule project (http://www.emule-project.net)
After the analysis of the emule project with CppDepend we observe that it uses mainly the MFC framework and the windows API .
Let’s see if the project is highly coupled with MFC , for 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 mostly used MFC classes:
MFC is used everywhere in the project, it uses the Gui components, Internet, Archive and Containers classes.
This high coupling has two major drawbacks:
- We can’t reuse easily the emule algorithm in other projects. We are forced to also use the MFC library if we want to reuse it.
- Any developer who want to integrate the emule project must master the MFC library.
Case II: OpenSTA project (http://sourceforge.net/projects/opensta/)
OpenSTA is divided into multiple projects and here are some project dependencies:
Divide the project into many modules can be very advantageous, it’s better to isolate the functionalities so we can use them in other projects and it simplify the complexity of the project.
Which projects use MFC?
We observe that not all the projects use the MFC framework and the big ones does not use it.
Which MFC classes are used?
OpenSTA uses mainly the OLE classes.
For the OpenSTA project a C++ developer who not master the MFC framework can integrate the project. they are many modules not using directly MFC.
Summary:
Isolating the use of the external framework can be very advantageous for all the project actors, try to keep it simple and avoid any unnecessary coupling especially with the business layer.
