De nombreuses bibliothèques et frameworks C++ sont disponibles, et les utiliser peut accélérer le développement de vos projets. Dans cet article, nous allons explorer les inconvénients d'une application C++ fortement dépendante d'un framework externe. Mais d'abord, quelle est la différence entre une bibliothèque et un framework ? Et pourquoi un couplage fort avec un framework peut-il avoir plus d'inconvénients qu'un couplage fort avec une bibliothèque ?
Voici une comparaison intéressante entre les deux, tirée de cet article:
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.Un framework peut aussi être défini comme ceci :
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.Pour résumer, un framework est plus intrusif qu'une bibliothèque, et il peut influencer l'architecture et la conception de votre application.
Par exemple, Qt et MFC sont deux frameworks C++ bien connus ; voici leurs définitions tirées de leurs sites web :
Qt :
Qt is a cross-platform development framework enabling your team to deploy a single codebase providing common APIs across all supported platforms.Et 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.Un framework est plus intrusif ; si une application y est fortement couplée, presque toutes les parties prenantes du projet seront affectées.
Le recruteur : Si un projet est fortement couplé à un framework externe, presque chaque développeur doit maîtriser ce framework, ce qui rend plus difficile le recrutement de nouveaux développeurs pour le projet. En effet, il faut chercher des développeurs C++ qui ont déjà une expérience du framework utilisé.
L'architecte et le concepteur : Lorsque le projet est fortement couplé à un framework externe, nous perdons en flexibilité, et toute évolution, migration ou adaptation du projet devient plus compliquée.
Le développeur : Chaque framework a ses propres complexités, et lorsqu'il est fortement couplé au projet, chaque développeur doit le maîtriser. Cela ajoute de la complexité au projet et peut affecter significativement le temps de développement et la qualité.
Le testeur : Il est très difficile d'isoler et de tester notre propre code lorsqu'il est fortement couplé à un framework. Parfois, le testeur doit faire un travail supplémentaire pour tester l'application.
Utiliser un framework externe peut accélérer le développement d'un projet. Cependant, nous devons l'utiliser avec prudence et éviter autant que possible tout couplage inutile.
Analysons quelques projets C++ open source et voyons quelles compétences un développeur doit avoir pour rejoindre leurs équipes de développement.
Cas n°1 : le projet Emule (http://www.emule-project.net)
Après avoir analysé le projet eMule avec CppDepend, nous observons qu'il utilise principalement le framework MFC et l'API Windows.
Voyons si le projet est fortement couplé à MFC ; pour cela, nous pouvons demander à CppDepend quelles méthodes utilisent MFC. Voici le résultat dans le graphe treemap :
Nous observons que presque toutes les méthodes utilisent le framework MFC, ce qui rend la base de code d'eMule fortement couplée à celui-ci.
Nous pouvons aussi rechercher les classes MFC les plus utilisées :
MFC est utilisé dans tout le projet : il utilise les classes GUI, Internet, Archive et Container.
Ce couplage élevé a deux inconvénients majeurs :
- Nous ne pouvons pas réutiliser facilement les algorithmes d'eMule dans d'autres projets ; nous devons aussi utiliser la bibliothèque MFC si nous voulons les réutiliser.
- Tout développeur qui souhaite rejoindre le projet eMule doit maîtriser la bibliothèque MFC.
Cas n°2 : le projet OpenSTA (http://sourceforge.net/projects/opensta/)
OpenSTA est divisé en plusieurs projets ; voici quelques-unes de ses dépendances entre projets :
Diviser un projet en plusieurs modules peut être très avantageux : isoler les fonctionnalités facilite leur réutilisation dans d'autres projets et réduit la complexité du projet.
Quels projets utilisent MFC ?
Nous observons que tous les projets n'utilisent pas le framework MFC, et que les plus gros ne l'utilisent pas.
Quelles classes MFC sont utilisées ?
OpenSTA utilise principalement les classes OLE.
Un développeur C++ qui n'est pas expert du framework MFC peut quand même rejoindre l'équipe OpenSTA, car de nombreux modules n'utilisent pas MFC directement.
Résumé
Isoler l'utilisation d'un framework externe peut être très avantageux pour toutes les parties prenantes du projet ; essayez de rester simple et évitez tout couplage inutile, en particulier avec la couche métier.