Codage en vu d'implémenter une interface graphique

Bonjour à tous !

Lorsque que l'on programme en C, on utilise des types standards de base (par exemple char * pour un string...) pour le coeur du programme. Mais lorsque l'on veut utiliser des interfaces graphiques, genre Qt ou gtk, il faut utiliser leur type de variable (par exemple qstring ou gstring).
Ma question : quelle est la façon la plus propre de coder un programme ? Doit-on utiliser dès le départ les types de variable de l'interface pour tout le programme ou au contraire, utiliser les types standards du C pour le coeur du programme et faire une conversion au besoin dans les types de l'interface graphique pour l'affichage (ou conversion dans l'autre sens pour la récupération des données saisies dans l'interface) ?

Plus généralement, doit-on anticiper l'écriture du code pour implémenter une interface graphique, ou alors celle-ci n'est juste qu'une couche supplémentaire au programme ?

Merci !

Normalement, l'interface graphique est une surcouche du cœur du programme. Le cœur est sensé en être indépendant.
Si demain tu trouves une bibliothèque plus magique que Qt, tu ne veux pas avoir à toucher au code du cœur.

D'ailleurs, nombreux sont les programmes dont le cœur est une bibliothèque sans interface, et le programme en lui même se contente de créer l'interface autour.
Par exemple, curl et libcurl.

Les bibliothèques utilisent leurs propres strings pour des raisons d'encodage.
Qt étant un cas particulier, puisqu'il fournit des services beaucoup plus riches, notamment le support intégré d'un système de signaux et slots.

La plupart des bibliothèques « mastodontes » proposent effectivement des modules d'usage très général qui servent de base à leurs solutions spécifiques. Ta question est : faut-il se retenir d'utiliser ces modules utilitaires hors du cadre d'application de la bibliothèque ? Comme très souvent la réponse est : ça dépend.

• As-tu réellement besoin des fonctionnalités supplémentaires ?
• Es-tu prêt à accepter les choix de conception des auteurs, qui cherchaient à couvrir un autre cas d'utilisation que le tien ?
• Acceptes-tu contraindre ton application à une bibliothèque d'interface graphique ? Peut-être voudras-tu plus tard en changer, ou opter pour une architecture de la forme client-serveur où l'UI est unilatérale (philosophie Unix).

Si tu as répondu « oui » à toutes ces questions et si ça te rend la vie plus facile, voici mon conseil : fonce.


Oui c'est cool et élégant l'abstraction, le cloisonnement des modules. Mais je cause d'expérience : n'en abusons pas. La vie est trop courte pour prendre en compte des scénarios qui ne se réaliserons jamais. « Ah ouais mais quand on changera de moteur..? » Et si ma tante en avait... Voilà au choix ce qui se passera dans le monde réel :

• on ne changera jamais de moteur ;
• le reste de l'application sera de toute manière obsolète et devra être réécrit ;
• les couches d'abstraction s'avèreront inadaptées au nouveau moteur (bon courage pour intégrer l'Unreal Engine à partir d'un modèle de wrapper prévu pour OpenSceneGraph, les gars !).

Citation:

---

Envoyé par rems14

Plus généralement, doit-on anticiper l'écriture du code pour implémenter une interface graphique, ou alors celle-ci n'est juste qu'une couche supplémentaire au programme ?

---

Bonjour

Une des méthodologies existante pour répondre à ce genre de question est la programmation MVC (Modèle/Vue/Contrôleur)

• Le modèle, c'est la façon dont tu stockes les données (par exemple dans une bdd, dans un fichier texte, etc)
• La vue, c'est la façon dont tu affiches et saisis tes données (tu as parlé de Qt mais ça peut aussi être des scanf/printf)
• Le contrôleur c'est les calculs qui traitent tes données pour en produire des résultats

Si tu dédies chaque partie à des fonctions spécifiques (ex: la fonction qui affiche tes données ne fait que ça) tu pourras plus facilement ensuite changer si tu en as besoin. Donc par exemple pour toi, ton contrôleur continuerait à travailler en char* ou char[] pour tes chaines, mais quand tu aurais besoin de charger ces chaines depuis Qt tu passerais alors par QString.toUtf8().data().
Je ne dis pas que c'est toujours facile ni toujours faisable à 100% (il m'arrive par exemple de mettre du "select * from table" dans mes fonctions IHM) mais c'est déjà un pas de franchi.

Citation:

---

Envoyé par Matt_Houston

Oui c'est cool et élégant l'abstraction, le cloisonnement des modules. Mais je cause d'expérience : n'en abusons pas. La vie est trop courte pour prendre en compte des scénarios qui ne se réaliserons jamais. « Ah ouais mais quand on changera de moteur..? »

---

Ben je cause d'expérience aussi, en 2007 j'ai commencé un truc à partir de rien donc je suis parti sur MySQL (pour des raisons diverses et variées dont l'une d'elles était que j'étais le seul à choisir et une autre était que je connaissais bien MySQL) et puis le truc a pris de l'importance, ce qui était une simple maquette au départ est devenu fonctionnel, il est passé de mains en mains et tout d'un coup on m'a dit "il faut maintenant qu'il travaille sous Postgres". Bin heureusement j'avais travaillé quand-même en MVC. Donc voilà, les expériences il y en dans toutes les situations.

Citation:

---

Envoyé par Matt_Houston

Et si ma tante en avait...

---

Bin ce serait ton oncle.

Merci pour vos retour d'expériences :)
Je préférais aussi séparer l'UI de programme en lui-même, mais je voulais d'autres avis.
Je vais me renseigner sur l'approche en MVC.

Merci bien !!!