Discussion :

[Davidbrcz]

Bonjour à tous.

Je vais d'ici quelqu'un temps réaliser une application assez conséquente pour un client. J'ai déjà bien écrémé le sujet, mais une question subsiste. En effet, l'application que je vais développer pourrai se passer d'une GUI. En pratique, cela ne serra pas le cas, car le client un veut une, mais en théorie, ce qu l'application fait est réalisable uniquement via la console.

Et là se pose une question, jusqu'au doit aller l'intrusion du framework qui va me permettre de réaliser la GUI (Qt dans mon cas) ?

Pour le moment, je vois deux solutions :
Solution 1 : D'un coté, j'ai mes classes métiers qui sont indépendantes de tout framework graphique, ça reste du C++ 'pur', autrement dit que de la STL/boost.
Et avec au dessus, mes classes graphiques qui auront pour rôle d'afficher une belle GUI. Ce qui m'ennuie, c'est le nombre de conversion que je vais devoir réaliser pour afficher le tout. Mais d'un autre coté, le changement de GUI serra plus facile au besoin. Cette solution respecte le DIP.

Solution 2: J'ai toujours mes classes métiers d'un coté, mais celles ci aurait fait un plongeon dans Qt. Ainsi, le développement serrait facilité (on peut utiliser la puissance de Qt partout), il n'y a pas de conversion à faire, mais un changement de GUI nécessite de réécrire une bonne partie de l'application.

Que me conseillez vous ?
Merci.

David Côme.

EDIT: La discussion ayant été supprimé à cause du rollback, ci joins l'ensemble des messages de la première discussion,si un admin pouvait les restaurer, merci. .

[PRomu@ld]

En fait, il faut toujours séparer l'IHM du code. Il y a plusieurs type d'architecture de programmation des IHM plus ou moins adaptées à ton cas. La liste peut être assez longue mais regarde quand même du coté de MVC, Seeheim, arch, PAC, ...

Mais garde à l'esprit qu'il faut toujours mettre à part l'IHM (même si c'est contraignant de temps en temps). D'autant plus que dans ton cas, l'IHM est visiblement secondaire alors autant ne pas en être dépendant.

[millie]

En fait, il faut toujours séparer l'IHM du code. Il y a plusieurs type d'architecture de programmation des IHM plus ou moins adaptées à ton cas. La liste peut être assez longue mais regarde quand même du coté de MVC, Seeheim, arch, PAC, ...

Des fois, je me dis quand même que c'est un peu n'importe quoi. Changer d'IHM (par exemple d'une application normale type Swing/QT à une application Web) demande quasiment de réécrire une très grosse partie même avec un modèle comme MVC (parfois, le traitement métier se retrouve dans le contrôleur alors qu'il faudrait ajouter des séparations supplémentaires).

[PRomu@ld]

Je suis aussi d'accord de temps en temps. D'autant plus que je dois avouer que c'est assez rare de changer d'IHM dans un projet (ça m'est arrivé une seule fois). Le gros avantage est aussi de pouvoir travailler plus facilement en équipe (si tout est bien découpé, et pas entremêlé ça aide de temps en temps)

[millie]

Le gros avantage est aussi de pouvoir travailler plus facilement en équipe (si tout est bien découpé, et pas entremêlé ça aide de temps en temps)

Oui, par contre là, les avantages sont indéniables

[souviron34]

Bonjour à tous.
Et là se pose une question, jusqu'au doit aller l'intrusion du framework qui va me permettre de réaliser la GUI (Qt dans mon cas) ?

Pour moi, il est clair que la séparation doit être totale. J'ai déjà réalisé des applis dont le code métier tourne simultanément sur Win, sur *nix avec X11/Motif, ou en langage de commande via script (y compris de TRES grosses applis).

Règle 1 : faire une analyse correcte pour réellement séparer en couches où aucune couche n'a connaissance de la couche supérieure.

Règle 2 : s'affranchir des contraintes (par exemple en C passer en paramètres des pointeurs sur des structures indépendantes contenant un pointeur void vers la classe parent, ce qui permet d'avoir un code métier complètement indépendant de la calsse parent).

Règle 3 : utiliser cette structure pour faire une API d'affichage indépendante de l'outil (pour les primitives : exemple Trace_Ligne, Trace_Texte, etc..).

Des fois, je me dis quand même que c'est un peu n'importe quoi. Changer d'IHM (par exemple d'une application normale type Swing/QT à une application Web) demande quasiment de réécrire une très grosse partie même avec un modèle comme MVC (parfois, le traitement métier se retrouve dans le contrôleur alors qu'il faudrait ajouter des séparations supplémentaires).

Désolé, mais c'est toi qui dit n'importe quoi, là...

Sans modèle particulier, sauf à la limite un modèle "en couches", le schéma exposé se fait souvent dans l'industrie (et heureusement, vu que le développement d'une IHM est en général 80% du temps de développement d'une appli).

Ce que tu proclames est justement la dérive constatée depuis une quinzaine d'années et mises en place par toutes les générations d'étudiants ayant appris uniquement avec des Frameworks.

[millie]

Désolé, mais c'est toi qui dit n'importe quoi, là...

Tu pourrais développer, car je ne vois pas du tout en quoi je dis n'importe quoi.

[souviron34]

Quand tu dis ça :

Des fois, je me dis quand même que c'est un peu n'importe quoi. Changer d'IHM (par exemple d'une application normale type Swing/QT à une application Web) demande quasiment de réécrire une très grosse partie même avec un modèle comme MVC (parfois, le traitement métier se retrouve dans le contrôleur alors qu'il faudrait ajouter des séparations supplémentaires).

Si l'analyse et la conception ont été bien faits, quel que soit l'IHM utilisée, ce ne serait qu'une petite partie du code.

Je te donne un exemple - vécu :

Dans l'exemple cité dans mon message précédent, un code (7 ans de développement total, 750 000 lignes de code), tournant sur *nix, et sous Win, avec GUI mais aussi sans GUI.

Le code du GUI en X11/Motif : 140 000 lignes, soit environ 19%.

Passage du GUI X11/Motif à un langage de commande : 2 mois. Code résultant : 5000 lignes.

Passage du GUI X11/Motif à Win (VC++) : 6 mois. code résultant : 90 000 lignes (des widgets existaient déjà qui n'existaient pas sous Motif).

Absolument aucun code métier dans les IHMs.

Absolument aucun changement de code métier pour changer d'IHM (en fait, un simple link à une bibliothèque différente).

[millie]

Alors, je n'ai pas été très clair dans ce que j'ai dit.

J'ai voulu dire qu'en utilisant certains modèles qui sont censés permettre d'être indépendant de l'IHM (notamment MVC), on est pas à l'abri de faire n'importe quoi. Il y en a qui écrivent du code métier dans le contrôleur (j'ai vu ça à plusieurs reprises en entreprise, et avec du code pas écrit par des étudiants !) et qu'il est donc nécessaire de réécrire une grosse partie du code.

Maintenant, si c'est bien fait, il y a une grosse partie commune entre les applis et une partie qu'il est nécessaire d'ajouter/réecrire (par exemple, le fait d'utiliser la molette pour zoomer sur du texte ou une image a un sens dans une IHM "normale" et n'a pas de sens dans une IHM en ligne de commande).

[souviron34]

lol ok on s'était mal compris alors..