Discussion :

[r0d]

Bonjour,

lorsqu'on part sur la conception d'un grosse application, il y a tout un tas de choix à faire. Notemment celui de la modularité: il faut découper notre programme en modules le plus indépendants possibles afin de faciliter le développement, les tests et la maintenance.

En c++ (et dans la plupart des langages il me semble), pour faire cela on va découper notre programme en bibliothèques, statiques ou dynamiques, qui seront autant de sous-projets.

Pour poursuivre la discussion et l'illustrer, prenons un exemple (presque) concret. Un programme BigProject, qui contiendra:
. une interface graphique relativement complexe (plusieurs écrans, toute sortes de contrôles, etc.)
. des accès à une grosse base de données (lecture et écriture)
. plusieurs thread permettant d'effectuer plusieurs tâches en parrallèle et faire des choses sans bloquer l'IHM
. plusieurs types de traitements de données très différents. Par exemple, un module qui traite des images, un autre qui fait des calculs sur des séries contenues en base de donnée, etc.
. une interface réseau qui permet d'échanger des données avec des serveurs (webservices avec SOAP par exemple) externes.
. un moteur de règles, qui s'applique à chaque résultat avant qu'il ne soit affiché

Première étape, appliquons un MVC "bourrin" => on obtiens 3 gros modules:
1. la gestion des données (base de données, modules réseau, traitements) [Model]
2. l'IHM [View]
3. la gestion des threads, l'organisation des tâches et des règles [Controller]

Si l'on en reste là, on va obtenir 2 grosses bibliothèques (Model et Controller) et un gros exécutable (View).

Maintenant la question est: doit-on continuer à découper chacun de ces trois modules en sous-modules sous formes de petites bibliothèques?

Plus précisément, les questions qui se posent sont:
1. la rapidité d'exécution: si on a décidé de séparer un module (une bibliothèque) en 2, mais qu'une des bibliothèque fait 1000 appels par seconde à une fonction de l'autre bibliothèque, ne va-t-on pas perdre en rapidité d'exécution?
2. maintenance: est-ce que ça ne devient pas trop compliqué au bout d'un moment, d'avoir 50 dlls/libs différentes, avec des dizaines de versions pour chacune?
3. gestion des dépendances: est-ce que les inter-dépendances entre les différentes libs peuvent finir par poser de gros problèmes? (dépendances circulaires par exemple)
4. statique vs dynamique: dans quel(s) cas est-il préférable d'utiliser des bibliothèques statiques ou dynamiques?
5. existe-t-il des "best practices" concernant ce découpage en modules?

[nikko34]

Ben euh.. ça dépend de l'appli non?

tu n'as pas forcément besoin de bibliothèques différentes, peut être juste une séparation en modules ( avec l'aide de namespaces ) suffit largement.

Après si tu veux un système de plug-in, une grande modularité qui te permet de changer de framework graphisme à la volée, là il faudra faire des biblio dynamiques.

Bon je suis pas spécialiste là dessus donc je voudrais pas dire de bêtise mais le linkage statique est pratique si tu veux pas avoir trop de dépendances à des libs, que tu ais tout direct dans ton appli avec la version que tu as choisi. Mais il sera plus gros et plus long à compiler.

Et idem si tu as plusieurs appli qui partagent des modules, là une librairie commune fera aussi l'affaire.

[3DArchi]

Salut,

1. la rapidité d'exécution: si on a décidé de séparer un module (une bibliothèque) en 2, mais qu'une des bibliothèque fait 1000 appels par seconde à une fonction de l'autre bibliothèque, ne va-t-on pas perdre en rapidité d'exécution?

Pourquoi perdrait-on en rapidité ? A part au lancement, lorsque la bibliothèque est chargée, ensuite le code est en mémoire comme le code de l'exe. Pourquoi ça impacterait les perfs ? (sauf si il y avait un inlining dans la première version).

2. maintenance: est-ce que ça ne devient pas trop compliqué au bout d'un moment, d'avoir 50 dlls/libs différentes, avec des dizaines de versions pour chacune?

Probablement. Surtout en gestion de conf et en intégration.

3. gestion des dépendances: est-ce que les inter-dépendances entre les différentes libs peuvent finir par poser de gros problèmes? (dépendances circulaires par exemple)

Ca, c'est un problème de design.

4. statique vs dynamique: dans quel(s) cas est-il préférable d'utiliser des bibliothèques statiques ou dynamiques?

5. existe-t-il des "best practices" concernant ce découpage en modules?

Réponse 3 : ne sait pas

[JolyLoic]

Je donnerais des réponses plus détaillées à l'occasion, si j'en ai le temps.

1. la rapidité d'exécution: si on a décidé de séparer un module (une bibliothèque) en 2, mais qu'une des bibliothèque fait 1000 appels par seconde à une fonction de l'autre bibliothèque, ne va-t-on pas perdre en rapidité d'exécution?

Avec un bon compilo et une lib statique : Non. Avec une lib dynamique, peut-être (j'ai déjà eu un écart de 10% de perfs).

2. maintenance: est-ce que ça ne devient pas trop compliqué au bout d'un moment, d'avoir 50 dlls/libs différentes, avec des dizaines de versions pour chacune?

Oui, et non... En général, une GrosseAppli ne vit pas toute seule, isolée. Elle collabore avec GrosseAppliVersionFree et GrosseAppliSurUnDomaineProche. Dans ce cas, des bibliothèques sont utiles.

3. gestion des dépendances: est-ce que les inter-dépendances entre les différentes libs peuvent finir par poser de gros problèmes? (dépendances circulaires par exemple)

S'il y a dépendance circulaire, c'est généralement qu'il y a mauvais découpage. Il existe des outils pour mieux visualiser les dependances entre bibliothèques, mais je n'n ai pas de véritable expérience.

4. statique vs dynamique: dans quel(s) cas est-il préférable d'utiliser des bibliothèques statiques ou dynamiques?

Pour moi : Statique : Option par défaut. Dynamique : Si on a besoin du dynamisme (plug-in...)

5. existe-t-il des "best practices" concernant ce découpage en modules?

Le seul livre que je connaisse sur le sujet est "Large scale C++ software design", mais je le trouve un peu gros et lourd à lire par rapport au contenu (intéressant néanmoins).

[3DArchi]

Je donnerais des réponses plus détaillées à l'occasion, si j'en ai le temps.
Avec un bon compilo et une lib statique : Non. Avec une lib dynamique, peut-être (j'ai déjà eu un écart de 10% de perfs).

J'imagine que c'est lié aux optimisations que peut faire le compilo/linker avec une lib statique. Parce que sinon, je ne vois pas quelle différence il peut y avoir ?

[Jean-Marc.Bourguet]

J'imagine que c'est lié aux optimisations que peut faire le compilo/linker avec une lib statique. Parce que sinon, je ne vois pas quelle différence il peut y avoir ?

Le probleme est qu'on associe generalement (au moins sous Unix), lib dynamique et PIC (Position Independant Code). Quand on compile vers du PIC, il y a un overhead (sauf si l'archi a ete concue pour ca, X86-64 par exemple a un mode d'adressage concu pour diminuer l'overhead). Mais on peut faire une lib dynamique sans compiler en PIC (on paie autrement, par un cout plus important au demarrage et par des difficultes a partager la lib entre processus).

[screetch]

l'avantage des DLL (sous windows) c'est de vérifier que le code n'a pas de double dépendance (ce qui est possible avec des libs statiques).
On ne peut pas avoir a.dll qui dépend de b.dll qui dépend de a.dll
alors qu'on peut avoir a.lib et b.lib qui dépendent l'un de l'autre

du coup cela permet de vérifier qu'on a pas d'appel "en amont", c'est a dire un code qui dépend d'une implémentation qu'on ne devrait pas connaitre.

Pour ma part, je me suis cassé la nenette a grand coups de macros et d'outil de build jusqu'a pouvoir activer un simple switch qui me permet de passer d'un système a 15 dll indépendantes, a une seule DLL et un executable et des plugins, voire même un build complètement statique ou les plugins sont "intégrés" a l'executable. Je peux ainsi vérifier les dépendances de projets, mais pour le build final il n'y a qu'une DLL et des plugins, et sur des systèmes exotiques sans chargement dynamique un seul executable. (vive les macros)

[Jean-Marc.Bourguet]

2. maintenance: est-ce que ça ne devient pas trop
compliqué au bout d'un moment, d'avoir 50 dlls/libs différentes, avec des
dizaines de versions pour chacune?

Oui, il y a un moment ou la decoupe est trop fine. Mais pour un gros
projet, 50 en est loin (pour l'appli principale sur laquelle je travaille,
on a 2 objets et 430 librairies -- dont une soixantaine sont plusieurs fois
dans la ligne de link)

3. gestion des dépendances: est-ce que les inter-dépendances entre
les différentes libs peuvent finir par poser de gros problèmes?
(dépendances circulaires par exemple)

C'est des problemes chiants mais pas bloquant. Mais elles denotent des
interdependances entre equipes qui sont plus penibles. Au final, on arrive
toujours a un organigramme fonctionnel et une archi logicielle qui tendent
l'une vers l'autre, et quand c'est l'organigramme fonctionnel qui commande
(pour des raisons plus ou moins bonnes, dans les bonnes il y a la
localisation geographique), on se retrouve avec des dependances
artificielles.

En prime, il ne faut pas sous-estimer le cout des techniques de
decouplages. Elles ne suppriment pas les interactions, elles les masquent.
Et dans une grosse appli, tu te retrouvent facilement a interferer avec des
interactions dont tu n'as pas connaissance et qui ne sont pas visibles dans
le code (deux observeurs sur un module qui interagissent a travers un
quatrieme et donc doivent etre enregistres dans un ordre donne par exemple).

4. statique vs dynamique: dans quel(s) cas est-il préférable
d'utiliser des bibliothèques statiques ou dynamiques?

Statique quand on peut, dynamique quand on doit. Les bibliotheques
dynamiques imposent une gestion des versions jusqu'a l'utilisation et
posent donc des problemes de validations impossibles si on n'est pas tres
rigoureux et la rigueur en la matiere est couteuse -- surtout si par manque
d'experience on ne sait pas a quoi il faut faire attention.

[jblecanard]

Salut !

1. la rapidité d'exécution: si on a décidé de séparer un module (une bibliothèque) en 2, mais qu'une des bibliothèque fait 1000 appels par seconde à une fonction de l'autre bibliothèque, ne va-t-on pas perdre en rapidité d'exécution?

L'explication avec l'overhead de M. Bourquet semble complète. Pourtant, je tiens à signaler un aspect utilisé sur le projet sur lequel je bosse, qui contient des milliers de dlls (et pas des petites). Un utilisateur donné ne va pas nécessairement charger toutes les dlls. Il va se concentrer par exemple sur une partie du programme, et par conséquent, seules les dlls qu'il va effectivement utiliser seront chargées, ce qui représente une économie en mémoire et en temps de chargement non négligeable. Peut être qu'il y a un travail à effectuer côté code pour que ce soit géré finement, mais en tout cas ça se fait.

Aussi, rien n'empêche une équipe de livrer une version dynamique et une version statique de sa librairie, en laissant à l'intégrateur industriel le choix final pour l'application.

Astuce hors sujet : si vous attachez le débugueur Visual à un processus qui a chargé plus de 500 dlls, il plante.

2. maintenance: est-ce que ça ne devient pas trop compliqué au bout d'un moment, d'avoir 50 dlls/libs différentes, avec des dizaines de versions pour chacune?

C'est l'éternel problème du juste équilibre, et comme dit plus haut, c'est beaucoup lié à l'organisation humaine. La granularité du programme sera aussi celle des équipes de développement, je ne pense pas qu'il y ai de formule magique. Au niveau des versions, si l'architecture de gestion du code source et le calendrier des livraisons sont bien conçus, ça ne devrait pas poser de souci.

3. gestion des dépendances: est-ce que les inter-dépendances entre les différentes libs peuvent finir par poser de gros problèmes? (dépendances circulaires par exemple)

Pour moi, la réponse est oui. Chez nous, des outils de gestion des droits peuvent empêcher des équipes de tirer sur du code dont ils ne sont pas censés dépendre. Les auteurs d'une librairie doivent donner explicitement le droit à d'autres de pouvoir les utiliser. Le problème est que c'est complexe à mettre en oeuvre sur la chaîne de compilation, et qu'une gestion juste "humaine" peut peut être suffire. En tout cas, c'est un problème qui requiert de l'attention, et un outil de visualisation et de surveillance des dépendances est indispensable, à défaut de pouvoir imposer des contraintes.

4. statique vs dynamique: dans quel(s) cas est-il préférable d'utiliser des bibliothèques statiques ou dynamiques?
5. existe-t-il des "best practices" concernant ce découpage en modules

Comme 3D archi, réponse 3, ne sait pas.