[Document d'Avant-Projet] C#, Qt, MFC Que choisir ?

**thebop** · 20/01/2010, 19h20

Bonjour à tous !

Je dois élaborer avec un partenaire un dossier d'avant-projet pour l'élaboration de prototype d'un logiciel musical. Le but final du prototype est d'être montré à d'éventuelles boîte d'édition de logiciel (comme Steinberg par exemple) pour débloquer des fonds et une équipe pour parfaire et vendre le logiciel.

Ma question est que j'ai beaucoup de mal à faire un choix sur l'architecture de mon programme... Et surtout quel est tout simplement celui qui est souvent retenu dans des logiciels professionnels (Cubase, Fruity Loops, and co).

D'un côté le C# est tendance et je commence à être un minimum calé dessus.
De l'autre côté le C++ est dans ma tête toujours privilégié dans ce cadre là, mais se pose alors la question MFC (qui a l'air putain de compliqué, j'ai déjà bossé dessus une fois pour un projet assez simple mais c'est un peu oldgen je trouve) et Qt ? (Jamais bossé dessus véritablement mais il a une très très bonne réputation (et se veut entièrement portable si je me rappelle bien).

Alors voilà, mon choix pour l'instant est arrêté sur Qt C++ mais je demande un avis sur la question.

Merci beaucoup

PS : Question subsidiaire : Est-ce que finalement les éditeurs en auront totalement rien à foutre et referont tout à zéro à leur sauce dès la "professionnalisation" du projet ?

**Médinoc** · 21/01/2010, 11h00

Si tu n'es pas un "pro" de Win32, n'utilise pas MFC. Déjà en étant pro, il y a un temps d'apprentissage assez élevé, surtout si tu es en mode Document/Vue.

**Mac LAK** · 21/01/2010, 12h57

Assez d'accord avec Médinoc, par contre je vais surtout répondre à ta question subsidiaire...

Tout dépend de la boîte : certaines ont comme principe de modifier la maquette initiale pour démarrer le projet, d'autres partent du principe que cette maquette n'est là que pour montrer un principe de base, et que l'on repart de zéro pour faire "proprement" le projet final.

Dans tous les cas, il peut être intéressant aussi de se pencher sur des systèmes RAD pour développer l'IHM, surtout si tu comptes faire une séparation propre (le cas normal, quoi...) entre IHM et traitement fonctionnel : un EXE autonome (peu importe le langage) pour l'IHM, et le traitement dans une DLL pouvant être appelée aussi bien par ton programme que par un tiers, dans sa propre application.

Surtout que si ton traitement est fait dans une DLL respectant une interface Win32 basique (en gros, des fonctions C et non pas C++ ou C#), alors ta DLL sera utilisable quel que soit le langage visé ou le compilateur choisi : C et C++ bien sûr, mais aussi VB, Delphi, C#, Python, Java, et j'en passe.

**thebop** · 21/01/2010, 17h43

Et c'est un peu la réponse à laquelle je m'attendais Mac LAK mais néanmoins je te remercie de l'avoir confirmée.

Je ne connais pas du tout l'astuce du dll. En clair tout mon modèle devrait être codé en C puis compilé en .dll. Il n'y aurait "plus qu'à" l'appeler ensuite dans un programme quelconque... (même si je me demande bien du coup comment ça marcherait... Je ne sais pas si je vais faire cette solution mais je vais me renseigner dessus quand même).

La majorité des programmes du marché sont codés avec quoi alors si ce n'est pas la MFC ?

**Mac LAK** · 21/01/2010, 19h19

Envoyé par thebop

Je ne connais pas du tout l'astuce du dll. En clair tout mon modèle devrait être codé en C puis compilé en .dll. Il n'y aurait "plus qu'à" l'appeler ensuite dans un programme quelconque... (même si je me demande bien du coup comment ça marcherait... Je ne sais pas si je vais faire cette solution mais je vais me renseigner dessus quand même).

En gros : ton code est découpé en fonction de base, comme "Ouvrir instrument", "Jouer note", "Fermer instrument", "Lire fichier de partition", "Ecrire fichier de partition", etc. Toutes ces fonctions sont mises dans une DLL au format WINAPI (= comme les DLL du système d'exploitation, donc accessibles par tous les langages).

Ensuite, ton IHM (écrite en ce que tu veux, à ce stade on s'en fout) se "contente" d'appeler les fonctions adéquates en réaction aux clicks de l'utilisateur, et d'afficher / présenter les données dans un format agréable à l'œil. Par exemple, si tu cliques sur le bouton "Save", ton IHM va afficher une boîte de dialogue standard pour demander le nom, et une fois celui-ci obtenu, elle va appeler la fonction de sauvegarde de la DLL en lui passant le nom choisi par l'utilisateur, et tous les paramètres "internes" (et cachés !!) permettant de savoir quoi sauver (ex : numéro d'identification interne de la partition en cours).

Sur le principe général de conception, cela veut dire qu'il faut en faire deux : la première, pour la librairie elle-même (la DLL, donc), pour savoir quelles sont les fonctions élémentaires à développer.
Ensuite, la conception de l'IHM, qui va permettre de créer les fonctionnalités macroscopiques, c'est à dire celles visibles par l'utilisateur final.

L'avantage d'une telle démarche, c'est qu'il y a de fortes chances que tu puisses éviter au maximum le code redondant, via l'analyse initiale des fonctions élémentaires. Le plus important étant de clairement séparer le code "IHM" du code "DLL", et de ne JAMAIS faire de mélange de l'un et de l'autre.

Envoyé par thebop

La majorité des programmes du marché sont codés avec quoi alors si ce n'est pas la MFC ?

T'as le choix : solution RAD (C++ Builder, Delphi, WinDev), VB, Qt, GTK, WPF, Java, et aussi les MFC bien sûr.
Cependant, les MFC sur un projet complexe, ça devient vite difficile à maintenir sans une rigueur énorme, alors que d'autres frameworks graphiques un peu plus évolués, comme il y a moins de code "manuel" à faire, il y a aussi moins de risques d'injecter des patchs / hacks / horreurs dans le code.

**thebop** · 21/01/2010, 19h35

Oui c'est ce que j'avais cru comprendre, le .dll est une représentation du Modele qu'on inclut dans une IHM externe. Pas con du tout, je ne sais pas si je vais me risquer à faire ça mais je vais y réfléchir (et oui évidemment le Modele doit toujours être indépendant de l'IHM c'est très important).

**Mac LAK** · 21/01/2010, 20h04

Non seulement c'est important, mais en plus, d'un point de vue financier, ça apporte pas mal de choses :

Indépendance en développement du modèle / IHM.
Comme tu as une interface commune valable sur à peu près tous les OS de la planète, tu peux développer de façon totalement séparée l'IHM et la DLL... Notamment en utilisant des langages différents !!
Par exemple, tu peux compiler ta DLL en utilisant le compilateur Intel pour ses performances, en C/C++, et obtenir d'excellents résultats.
Cependant, pour l'IHM, une solution RAD et fiable (perso, je privilégie Delphi pour ça) permettra d'avoir une IHM rapide à développer, à maintenir, et robuste qui plus est... Sans poser de problèmes d'interface entre les deux !
Indépendance en validation du modèle / IHM.
Valider le modèle est long et coûteux, et devoir se retaper une validation à 100% pour cause de corrections mineures d'IHM, ça coûte beaucoup. Alors que là, si le modèle n'a pas été touché (cas "normal"), et que tu corriges l'IHM ou que tu la localises, tu n'as pas à revalider le fonctionnel mais juste l'IHM, ce qui est plus rapide.
Côté validation du modèle, il est possible d'automatiser ça à 100% (via un script et/ou un programme dédié), d'y intégrer les tests de non-régression et tutti quanti : la validation se fait alors rapidement, le plus long étant de créer les scripts/programmes de tests de façon à ce qu'ils couvrent tous les cas connus.
Portabilité du modèle et/ou de l'IHM :
Changer de technologie d'IHM, ou de système d'exploitation, est plus facile car il existe un "tronc commun" (l'interface DLL) à respecter. On peut donc paralléliser le portage.
Source de revenus supplémentaire :
Tout le monde n'a pas forcément besoin / envie de ton IHM... Par contre, les fonctions de base peuvent intéresser des gens qui ont déjà leur propre environnement, et qui sont intéressés par les fonctions spécifiques de ta DLL.
Dans un tel cas, tu peux alors leur vendre la DLL comme librairie COTS, alors que si tu avais un programme monolithique, tu n'aurais rien pu leur fourguer.
Abstraction des drivers :
Comme tu as déjà fait une séparation propre, tu peux sans problème en créer une deuxième (tu as déjà fait le plus difficile), et avoir en fait deux DLL à bas niveau : une DLL "générale", implémentant les fonctions de haut niveau, et une DLL "système" qui se connecte au système d'exploitation et aux drivers.
Ainsi, tu as donc une DLL portable (la générale) contenant tout le savoir-faire complexe : algorithmes, filtres logiciels, traitements, etc. et une DLL non-portable se connectant aux drivers et aux fonctions de l'OS (ex : threads, mutex, etc.), et qui ne fait que publier une interface "portable" vers ta DLL générale.
L'avantage, c'est que pour basculer (par exemple) des drivers son MDI vers des drivers DirectSound, ou des drivers spécifiques, tu n'as qu'une DLL à modifier (et à revalider !!!). De même, pour porter ton logiciel sur un autre système d'exploitation, seule la DLL "système" sera la cible d'un "gros" effort, l'autre ne demandant qu'une simple recompilation.
Cela permet également de s'adapter plus facilement aux évolutions des OS et du matériel (ex : utilisation d'une nouvelle fonction câblée au lieu d'une fonction anciennement assurée à 100% par le soft).
Documentation simple du code DLL :
Ta DLL étant, au final, une bibliothèque comme les autres, tes développeurs d'IHM sont alors les "clients" des développeurs DLL. Un outil très pratique pour faire la doc de la DLL peut être un système comme Doxygen (génération automatique de documentation depuis le code source), ce qui te permet d'avoir une excellente qualité documentaire sur le "bas niveau", et surtout en cachant la "tripaille" aux dévs IHM qui ne doivent JAMAIS avoir besoin de le savoir. S'ils en ont réellement besoin, c'est un problème de conception, que tu peux alors corriger.
Côté revente de la DLL "seule", ta doc client est alors déjà prête, donc gain d'argent là aussi...

Tu peux encore avoir d'autres avantages, qui dépendent de ton objectif commercial et des contraintes spécifiques à ta boîte. Mais ceux que je t'ai donné sont, eux, valables partout.

Après, à toi de voir si tu veux tenter le coup, mais je sais qu'à ta place, je n'aurais pas d'hésitation... Le temps que tu vas "perdre" en conception et en initialisation du projet, tu vas le gagner dix fois en validation et en maintenance, et je parle d'expérience.

**thebop** · 21/01/2010, 20h18

Vraiment un GRAND merci à toi pour avoir pris le temps de tout me détailler (je n'en demandais pas tant mais j'en suis ravi). Je m'en vais réfléchir de ce pas à ce nouveau type de programmation avec de nouveaux concepts plein les yeux.

**Mac LAK** · 22/01/2010, 10h08

Envoyé par thebop

Vraiment un GRAND merci à toi pour avoir pris le temps de tout me détailler (je n'en demandais pas tant mais j'en suis ravi). Je m'en vais réfléchir de ce pas à ce nouveau type de programmation avec de nouveaux concepts plein les yeux.

De rien, je détaille aussi pour les "curieux de passage" en fait... Mais disons que la première fois que j'ai voulu faire les choses proprement, il m'a fallu convaincre ma direction de me filer les heures de développement supplémentaires (et apparemment "inutiles"), donc j'ai aligné justement ce genre d'arguments... Et bien entendu, ça a aussi payé sur le moyen/long terme, et rentabilisé largement le "temps perdu" initialement. Mais un financier, c'est (caricaturalement, je précise) aussi binaire qu'un ordinateur : ça se résume à "rentable" et "pas rentable". Quand tu peux lui prouver que c'est rentable, en général, il te soutient sans problèmes... Encore faut-il avoir les éléments pour le lui prouver !

J'espère pour toi qu'il en sera de même avec ton projet. Bon courage pour la suite des opérations !