Discussion :

[omc24]

Bonjour,
Mon problème est, je pense, assez classique. Aussi je vous demande conseil quand au choix du design pattern le plus adapté.

Pour des besoins en applications scientifiques, j'ai besoin de faire du calcul intensif où je maltraite sans vergogne mes classes.

Dans un deuxième temps j'ai besoin d'afficher des résultats.
Cela m'embête de mettre dans mes classes des éléments ne servant pas au calcul mais qui sont juste là pour faire jolis (couleurs, épaisseurs des traits, etc...).

J'ai vu la pattern du décorateur qui répond à mes besoins, mais cela est tout de même un peu intrusif... Une idée ?
Merci !

[Emmanuel Deloget]

Bonjour,
Mon problème est, je pense, assez classique. Aussi je vous demande conseil quand au choix du design pattern le plus adapté.

Pour des besoins en applications scientifiques, j'ai besoin de faire du calcul intensif où je maltraite sans vergogne mes classes.

Dans un deuxième temps j'ai besoin d'afficher des résultats.
Cela m'embête de mettre dans mes classes des éléments ne servant pas au calcul mais qui sont juste là pour faire jolis (couleurs, épaisseurs des traits, etc...).

J'ai vu la pattern du décorateur qui répond à mes besoins, mais cela est tout de même un peu intrusif... Une idée ?
Merci !

Il n' s'agit pas à proprement parler d'un pattern, mais d'un système plus général : d'un coté, tu as des données auxquelles tu associes un ensemble de comportements codifiés - c'est ce qu'on appelle le modèle (ou modèle métier; ou avec des noms encore plus étrange). De l'autre coté, tu as la gestion de l'interface graphique, séparée en deux parties :

1) l'affichage, qui prends les données dans le modèle afin de les afficher. C'est la Vue.

2) le système de gestion des entrées utilisateurs, qui permet à l'utilisateur d'agir sur le modèle, par exemple pour lancer un calcul spécifique ou pour déterminer un ensemble de données à injecter dans les fonctions définies. C'est ce qu'on appelle un Contrôleur, parce qu'il permet de contrôler ce que fait l'application.

L'ensemble est une triade célèbre, parfaitement inapplicable en l'état, et qu'on appelle triade MVC (pour Modèle/Vue/Contrôleur).

Dans ce cadre, tes classes "Vue" inspectent tes classes "Modèle". Dans le même esprit, tes classes "Contrôleur" ont la possibilité de modifier ce modèle (ou de lui donner l'ordre de se modifier, ce qui revient au même). Le pseudo-diagramme de classe proposé dans l'article de Wikipedia donne une idée de l'architecture générale. Sache toutefois que cette vision très haut niveau sera impossible à implémenter telle quelle. Ce que tu va implémenter, c'est un système similaire, généralement appelée MVC hiérarchique ou PAC (Présentation-Abstraction-Contrôleur; a noter que ce n'est pas le même contrôleur. Ne sont-ils pas minions ces informaticiens, à utiliser les mêmes mots pour des concepts différents ? ). Pour simplifier, PAC est comme MVC, mais il admet qu'on ne peut pas représenter la totalité du modèle avec une seule vue. Il découpe donc MVC en mini-MVC d'application locale (par exemple, une boite de dialogue permettant de modifier les coefs a,b de l'équation d'une droite).

[omc24]

Merci de ta réponse,
Oui le modèle vue-contrôleur est séduisant mais mon implémentation de ce design, heu pardon modèle , n'est pas trés satisfaisant.

Je des tas de std::map qui associent à un objet un autre objet que j'appelle "décorateur" : couleurs, etc...
Cela permet d'associer des attributs décoratifs à des classes, mais cela rend le code assez illisible et donc.... tout pourrave !

As-tu des exemples d'applications ?

Sinon, lors de la visualisation mes objets sont en lecture seule, je ne touche pas à leurs attributs.