Discussion :

[Syarko]

Bonjour,

Je possède actuellement une application sous Visual C++ que j'aimerais "decouper" en différent module. En effet, c'est un peu le bordel dans le code donc j'aimerais separer un peu les différentes parties du logiciel pour avoir une meilleur lisibilité. Je voudrais donc separer le logiciel en plusieurs petites application Win32, et que ces application s'appellent entre elles. Déjà, est ce que je peux faire ceci avec des application Win32 console ? Et comment faire en sorte que je puisse appelle cette application avec des paramètres d'entrés, et qu'elle retourne en sortie d'autres paramètres que je pourrais traiter par la suite ?

Merci de votre aide

[ternel]

Sans faire des applications, tu peux essayer de faire une fonction principale par partie.
Ces fonctions seraient approximativement les main de chaque applications (sans la partie conversion de la ligne de commande en arguments concrets).

Si cela s'avère un peu délicat, il peut être intéressant de faire une classe représentant chaque module.

Pour répondre à tes questions:
Les applications win32 consoles sont possibles, mais il faudra les appeler avec l'horrible system(). Elles sont même plutot les meilleures candidates parmi les applications.
Des bibliothèques seraient plus adaptées (quite à écrire une application autour de chacune).

La fonction main possède une signature pour les arguments: int main(int argc, char*[] argv), le int étant le nombre d'éléments du tableau, qui lui contient les arguments.
il y a deux garanties: argv[0] contient le nom de la commande (le nom du binaire compilé, en gros), et argv[argc] == NULL.

[Syarko]

Enfin, il existe déjà des classes et des fonctions principales par grosses parties du logiciel. C'est surtout que je veux séparer afin de faire différent modules que je puisse réutiliser dans d'autres applications, et pouvoir également faciliter la "maintenance" (si on peut appeller ca comme ca) du code, afin de ne pas a avoir a chercher dans le fin fond du fichier ce que je veux changer.

[ternel]

Alors ce sont des bibliothèques que tu veux constituer.

[Syarko]

Donc faire des DLL serait beaucoup plus approprié dans mon cas ?

[stendhal666]

tu peux aussi passer l'output d'un programme comme input à un autre programme avec un fichier batch.

Ou même des bibliothèques statiques, plus simplement. Les DLL peuvent poser des problèmes assez horribles à régler, c'est le fameux "DLL Hell".

Là où je m'étonne un peu, c'est que C++ donne pas mal d'outils pour découper son code en interfaces bien découplées: les namespaces, les fichiers, les classes, la refactorisation via template... sans devoir passer par des DLL ou un découpage en applications indépendantes: est-ce vraiment la peine ou plutôt aussi pour voir?

[Syarko]

Enfaite j'effectue actuellement un stage en informatique, et disons que c'est ce qu'on me demande .

[ternel]

Alors demande plus de détails sur le niveau de découpage, et l'interaction voulue entre les parties.

Tu peux utiliser un script (batch ou bash) pour appeler plusieurs programmes, qui communiqueront par fichiers interposés, ou alors en étant "pipés" entre eux.
Tu peux utiliser des bibliothèques et n'avoir au final qu'un programme, mais pouvoir réutiliser les morceaux.

Il y a des tas d'autres possibilités.

En fait, tu découvres la plus grosse difficulté du développeur: se faire demander quelque chose avec assez de précision.
C'est à dire faire rédiger un cahier des charges.

[bretus]

Ou même des bibliothèques statiques, plus simplement. Les DLL peuvent poser des problèmes assez horribles à régler, c'est le fameux "DLL Hell".

Pas pire que l'enfer de devoir connaître toutes les dépendances de ses dépendances... Il suffit de déployer les DLL dans le même dossier que les exécutables.

Après, nettoyer du code pour nettoyer du code et découper pour découper, ça amène à se tripatouiller la cervelle pour peu de résultat. Segmenter un exécutable en plusieurs sans avoir une idée précise de réutilisation de ces exécutables dans un autre contexte me semble être du même ordre.

Pour la lisibilité du code, je pense que c'est pas une mauvaise chose de faire en sorte que Doxygen génère naturellement une doc compréhensible et d'organisée. Ça amène à poser les bons namespaces, à planquer les détails d'implémentations dans des namespaces detail, etc. Après, tu appliques une règle bibliothèque = namespace et exécutable = dossier dans app et hop : Le tour est joué.

[white_tentacle]

Un autre avantage à séparer en bibliothèque, c’est que ça empêche toute dépendance circulaire (hormis les cas où c’est strictement nécessaire, qui relèvent en général du détail d’implémentation). Et c’est vraiment une bonne chose d’un point de vue design.

Si le code est bien foutu, la séparation en différentes bibliothèques doit être effectivement triviale. Si c’est un fouillis immonde, ça peut se révéler beaucoup plus complexe

[Laurent 1973]

Je vois moi aussi un autre intérêt à bien séparer les différentes couches du logiciel: tester unitairement.

Si mes couches son isolables, c'est plus facile de mettre en place du test unitaire: il "suffit" de replacer les couches supérieure et inférieur par une fausse couche qui simule l'interaction avec des données contrôler.
Ainsi, on peux par exemple, tester correctement un traitement sans avoir besoin de la couche de persistance (fichier, BD, ...): une couche bouchon renvoie les données que l'on souhaite et même au limite.