The hidden cost of a high coupling with external frameworks.

Using frameworks accelerate the development of your projects, currently and for each language there  are many thousands of frameworks and libraries, each one of them has its advantages and its inconvenients and almost every project use at least one external framework. However make your project highly dependent to  an external framework comes with a price.

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

Human resource recruiter:
If a project is highly coupled with the external frameworks, the HR must search for a developer who master also the frameworks used which makes its task more difficult.We can discover that when reading some job offers, where sometimes many frameworks and libraries are  mentioned.

Architect and designer:
When the project is highly coupled with other frameworks 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 will add more complexity to the project and it will have a big impact on the developement 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 advanced server configuration like for the J2EE servers.

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

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

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

After the analysis of emule with CppDepend we observe that it uses MFC and ATL libraries



Let’s see if the project is highly coupled with MFC , for that we can ask CppDepend which classes use the MFC classes and here’s the result:



We observe that almost all the methods use the  MFC framework which makes the emule code base highly coupled with it.

We can also search for the  mostly used MFC classes:


MFC is used for the Gui, Internet, Archive and Containers. This high coupling makes the task difficult to use the emule algorithm in other projects and using other frameworks. If the algorithm was isolated into different namespace or maybe in 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 master the MFC library.


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



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


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

Which projects use MFC?



We observe that not all projects use MFC and the big ones do not use it.

Which MFC classses are used?


Many MFC classes are used, specially the OLE classes.

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

Summary:

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

Leave a Reply

Your email address will not be published. Required fields are marked *