Impact of high coupling with external frameworks

When I searched for a job as C++ developer after finishing my studies, the job offer was many times like this:
“You search for a C++ developer who master MFC, ATL, COM, and Database…” its sound like “You search for a C++ Guru”.

At this time I thought that’s normal and I must master all these skills, but after many years as C++ developer I knew that this kind of offers can indicate a high coupling of the project with external frameworks.

Using frameworks accelerate the development it can be used for GUI, database, files and others needs, but using it when it’s not necessary can complicate the project, for example for business layer we just need POCO objects.

Let’s see the impact of high coupling for different actors.

Human resource manager:
If a C++ project is highly coupled with external frameworks, the HR must search for C++ developer who master all the frameworks used, and now it’s very difficult to find a good C++ developer and find one who master other frameworks can be very difficult.

Architect and designer:
When the project is highly coupled with other frameworks we lose of flexibility, and any migration or adaptation of project to other context (WebService,Console,…) will be difficult.

Developer:
Any framework has its difficulties and we need some time to master it, and adding complexity of other frameworks to the project can add an overhead.

Tester:
For unit test it’s very difficult to isolate just our code and test it if it’s highly coupled with other frameworks.

So it’s nice to use frameworks to accelerate the development but use them carefully and avoid as possible unnecessary coupling.

Let’s analyze some open source project to discover what skills needed to integrate the development team.

Case I: Emule project (http://www.emule-project.net)

After analyzing emule with CppDepend we observe that it’s use MFC and ATL libraries




Let’s see if MFC is used in the whole project, for that we can ask CppDepend whitch classes use MFC classes and here’s the result:




we observe that MFC is used in the whole project, but how many classes of MFC are used and which ones are mostly used ( Gui,Containers,Archive,..)?

Many MFC classes are used and it concerns Gui,Internet,Archive and Containers.

The question is : Could you use the emule algorithm with other frameworks and in other contexts?

The answer is yes but it needs some overhead to disociate the busness layer from MFC.

If the algorithm was isolated into different namespace or maybe another module it can be reused in many other projects that needs the same behavior.


What about ATL ?

Emule use only some ATL classes, essentialy CString.

We can conclude that any developer who want to integrate the emule project must perform MFC library and ATL skill is not necesary.


Case II: OpenSTA project (http://sourceforge.net/projects/opensta/)




OpenSTA is divided into multiple projects and here's some project dependencies:

dividing project into diffierent modules can be very advantageous, it's better to isolate functionalities, we can use them in other projects and it simplify the complexity of project.

Which projects use MFC?




We observe that not all projects use MFC and the big ones d'ont use it.

Which MFC classses are used?

many MFC classes are used and especially OLE classes.

For OpenSTA project C++ developer who not master MFC can integrate the project.

Conclusion:

Isolationg the using of external frameworks can be very advantageous for any actor, so keep it simple and avoid any unecessary coupling especialy for business layer.