Discussion :

[picomz]

Bonjour,

Désolé pour le titre assez vague, je vais essayer d'expliquer plus clairement mon problème.
Je fait une application avec interface graphique et j'essaye un maximum de séparer la partie interface de la partie evenements dans mon application.

En gros j'ai une classe Interface qui contient toutes la partie présentation et une classe Actions qui est appellé par la classe Interface lorsque l'utilisateur demande un traitement.

Déjà, est-ce que ce genre de conception vous semble correct ?

Mon deuxième problème, c'est qu'il y'a certaines variable que je doit conserver dans toute mon application, mais qui ne sont pas spécialement lié à une classe en particulier et je voudrais savoir où les mettres ? Est-ce qu'il faut que je fasse un singleton pour ces variables ? Mais dans ce cas j'ai peur de finir par avoir tout simplement une classe poubelle avec plein de variables globales dedans...

Est-ce que vous avez des conseils à ce sujet, j'arrive pas à trouver des livres sur ce sujet.

Merci d'avance

[bruno_pages]

Bonjour et bon noel !

Je fait une application avec interface graphique et j'essaye un maximum de séparer la partie interface de la partie evenements dans mon application.
...
Déjà, est-ce que ce genre de conception vous semble correct ?

Oui !

Cependant je ne peux pas ne pas faire la remarque suivante, qui va sans doute faire hurler les puristes (c'est d'ailleurs pour cela que je ne peux pas ne pas le faire ) : il y a les principes tout blancs et propres sur eux, et il y a le monde reel avec quelques belles nuances de gris (et c'est cela qui le rend interessant).

Explication avec quelque chose que je connais bien : Bouml. Le modeleur UML gère à la fois une partie graphique grace à l'excellent Qt, et entre autre une représentation interne (non graphique) des éléments du modèle. Une des informations devant être mémorisée est l'arbre des éléments, ainsi une classe contient des membres, les classes étant elles même contenues dans des vues etc. Si je respecte à 100% la séparation graphique - reste du monde, je me retrouve avec deux arbres : celui du browser (géré via les classes Qt) et le mien, ce qui prend évidemment plus cher en mémoire et en temps d'exécution.

Comme mon but est de laisser la mémoire et le CPU faire des choses utiles et non être dépensés inutilement du point de vue de l'utilisateur de Bouml (la mémoire n'est jamais assez grosse, et le CPU n'est jamais assez rapide, pensez le contraire est une erreur et abouti à la longue liste des usines a gaz !), l'arbre des éléments repose sur celui du browser. Cela a d'ailleurs eu d'autres conséquences, mais je pense avoir eu raison, cela ne me pose pas de problèmes particulier, et vu les benchmarks le résultat escompté est atteind.

Pour choisir tout est affaire de pondération, dans mon cas je me repose sur Qt qui m'offre nettement plus que du graphisme pur, et la partie graphique n'est pas une partie négligeable dans le modeleur.

Ce que je cherche à te dire, c'est qu'il faut d'abord chercher à suivre des règles comme celle que tu énonces qui rendre les choses propres et maintenable, mais qu'il faut aussi savoir les appliquer intelligemment.

Mon deuxième problème, c'est qu'il y'a certaines variable que je doit conserver dans toute mon application, mais qui ne sont pas spécialement lié à une classe en particulier et je voudrais savoir où les mettres ? Est-ce qu'il faut que je fasse un singleton pour ces variables ? Mais dans ce cas j'ai peur de finir par avoir tout simplement une classe poubelle avec plein de variables globales dedans...

Je pense que tu as répondu toi même à ta question : si elles ne sont pas liées à une classe ... ne les lie pas à une classe, même via un singleton. Ce n'est pas parce que tu écris objet que tout doit passer par des classes, faire l'inverse serait appliquer la règles écrire objet de façon stupide car cette règle n'est pas un but mais un moyen. Maintenant évites quand même d'avoir trop de variables globales déconnectées de toute classe, car c'est à priori le signe d'un problème de design.

Bon developpement

[picomz]

Ok, merci beaucoup pour ta réponse.
Ca réponds parfaitement à mes questions, je vais pouvoir coder plus sereinement à partir de maintenant