Tiens, le topic de Folco sur les façons de coder m'a rapellé un des nombreux posts que j'avais l'intention d'écrire, alors je vais le faire tant que j'y pense.

En observant la façon dont sont conçues les applications, on observe souvent deux façons de faire.Une application en console avec un parsing intégral des paramètres de texte, et par dessus, une interface graphique qui s'interface avec le mode texte de l'application.
Je l'apellerai le « modèle Linux », vous comprendrez pourquoi.
Une application graphique, monobloc, contenant tout le code, logique et l'interface.
Je l'apellerai le « modèle Windows », bien que cela soit également applicable aux applications OSX.

Le modèle Linux est dérivé d'une habitude à toujours vouloir des utilitaires en ligne de commande, utilisables dans des scripts, mais s'adapte mal ailleurs. Les interfaces construites par dessus le mode texte souffrent d'une rupture brutale avec le modèle de données de l'application, rendant l'interfaçage et la synchronisation entre les deux mondes (texte et graphique), très difficile. Parfois, la partie graphique va devoir réimplémenter des traitements déjà faits par l'application en mode texte, car elle n'a aucun accès direct au code de celle-ci… Celà conduit souvent à des interfaces de piètre qualité, qui marchent pour un oui ou pour un non, mais ne savent pas toujours vous remonter la raison exacte des erreurs.

Le modèle Windows a été fait pour un monde graphique, où la ligne de commande joue un rôle très marginal. Dans ce cas, pas la peine de concevoir un quelconque mode texte, et la conception d'interfaces graphiques est d'autant plus aisée.

Si chacun de ces deux modèles peuvent sembler avoir leurs avantages, soyons honnêtes… Moi je les trouves tous les deux complètement nuls.

Il existe une autre façon de faire…Découpler le code de l'application du code de l'interface, par exemple en plaçant le code de l'application dans une librairie séparée. De cette manière, il est possible de créer plusieurs interfaces indépendamment des fonctionnalités de l'application. Le code ainsi produit est réutilisable, et facilement modifiable. L'interface graphique et l'interface texte bénéficieront du même ensemble de fonctionnalités, directement accessibles.
Bien évidemment, cela implique de développer deux interfaces différentes, mais pas nécéssairement simultanément…
Une application bien codée devrait toujours suivre ce modèle (même si elle est au final, et par souci de simplicité, compilée en un seul fichier) ou un modèle dérivé. Ne serait-ce parce que cela implique aussi une façon propre de structurer le modèle de données.
Allons un peu plus loin maintenant. Et répondons à la question: Pourquoi je vous parle de tout ça ?
Et bien d'abord parce que je me suis rendu compte, après avoir codé pas mal de trucs, que mon code propre tendait très fortement vers ce modèle, et que c'est vraiment aisé d'en dériver deux interfaces (texte/graphique) sans avoir trop de code à écrire.
Ensuite, parce que cela permet de concevoir des applications multi-plateformes décentes, offrant une interface native à chaque couple système d'exploitation + interface (graphique ou texte…). Cela pourrait aussi être un jeu, avec une interface DirectX pour Windows, OpenGL pour tout le monde, DirectFB pour Linux, etc… Vous voyez le dessin ?


En gros, ce que je suggère, c'est de coder l'application en tant que bibliothèque (.so, .dll, .dylib, ce que vous voulez…), et séparément, de coder une (ou plusieurs) interfaces en tant qu'éxécutables (.exe, a.out, ce que vous voulez…).
Ce n'est pas un concept de back-end (l'application va utiliser son interface comme un plug-in) ou de front-end (le « modèle Linux » ), mais bel et bien quelque chose de différent que je propose.

Peut-être cela a-t-il déjà un nom d'ailleurs, mais ça, je n'en sais fichtrement rien.