Besoin d'orientation pour des choix concernant l'interface graphique d'un programme

Bonjour,

L'année dernière j'ai commencé à coder une IA de poker. Avec mes faibles connaissances en informatique (j'étais en Terminale) j'ai réussi à recoder un moteur de jeu de poker, mais avant de m'attaquer à la partie IA, je voulais mettre le tout dans une interface graphique sympa avec une table, des joueurs, leur tapis à la table devant eux, et quelques onglets pour changer les paramètres de mon programme sans avoir à bouger les variables et instancier les objets à la main dans mon code.

Petit hic là, ça ma l'air assez dur sans aucunes connaissances là-dessus, j'ai donc ramé, j'ai regardé quelques tutos sur les interfaces graphiques qui commençaient généralement par des explications sur les délégués et les événements, ou alors j'en avais lu un entièrement sur le modèle DAO sur ce site (si je ne me trompe pas, le principe était de séparer le programme en plusieurs couches (métier, données, interface je crois ?) et les relier avec Spring, j'ai pas trop compris, je ne pourrais pas l'appliquer à mon programme, je ne sais même pas si l'interface graphique que je veux est faisable avec ce modèle.

Au final le projet est en stand-by car je ne sais pas trop où je vais, je ne sais pas comment je suis censé structuré mon programme. Cette année je suis en maths sup, l'info qu'on fait est assez théorique, avec des langages de haut niveau alors j'ai rien appris ni sur les interfaces graphiques ni sur le C# et je ne suis pas avancé.
Peut-être vaut-il mieux que j'utilise une librairie faite pour les interfaces graphiques, pour que je puisse travailler à plus haut niveau ? Pourtant la création d'interface graphique m'a l'air assez simplifiée sur Microsoft Visual C# Express (que j'utilise) alors peut-être que je n'avance pas seulement parce que je cherche au mauvais endroit ?

Je vais vous expliquer quel type d'interface graphique j'aimerais obtenir, j'espère que vous saurez m'orienter.

Déjà voici la liste des classes que j'utilise :
Pièce jointe 179041

Aucune classe n'hérite d'une autre.
La classe Table contient un attribut game de type Game, avec toutes les infos sur la partie en cours sur cette table, dans cette classe Game y a des joueurs (classe Seat), etc...
Concrètement je voudrais que mon programme ressemble à une fenêtre sur laquelle il y a une table, on pourrait changer le nombre de places sur cette table à l'aide d'un champ (l'interface modifierait donc l'attribut maxSeats de ma classe Table), ce qui modifierait l'affichage de la table directement. Le moteur de jeu attend la décision d'un joueur, et je voudrais pouvoir utiliser l'interface graphique pour récupérer la décision du joueur (ou d'une classe IA s'il s'agit d'une IA), du coup il faudrait que ma classe Seat (qui représente un joueur à la table) puisse demander à l'interface graphique d'afficher un certain nombre de boutons, puis d'attendre l'appui de ceux-ci, puis redonner cette saisie à la classe Seat qui retournerait son résultat au moteur de jeu qui continuerait la partie.
J'aimerais également pouvoir afficher des onglets dans ma fenêtre, qui permettent d'aller modifier des paramètres (il s'agit donc encore une fois de modifier les attributs de classes déjà instanciées à partir de mon interface graphique).


Comment j'ai procédé ?

Pour le moment j'instancie ma fenêtre dans ma classe Program
Ensuite ma table est initialisée dans la classe Program également, les joueurs également, les joueurs sont ajoutés à la table, le programme vérifie quels joueurs sont prêts à jouer, les ajoute à une classe Game, et après je démarre la partie à l'aide d'une méthode StartNewGame() dans ma classe Game, qui lance le moteur de jeu, c'est cette classe Game qui va calculer les actions possibles par chaque joueurs (Seat) quand c'est leur tour de jouer, et de leur demander de prendre une décision, et c'est là que j'aimerais faire intervenir mon interface graphique.

Le fait d'instancier ma fenêtre dans Program est-il mauvais ? Car aucunes de mes classes ne peuvent voir ma fenêtre, pourtant je ne peux pas non plus faire une fenêtre par classe, je ne peux pas non plus créer mes classes dans la classe Program, car je ne pourrais pas instancier mes objets.
J'ai l'impression que la plupart de mes problèmes viennent du fait qu'il faut que j'utilise massivement les événements alors que je ne les maîtrise pas du tout, et également du fait que la structure de mon code est à revoir car je n'ai pas l'habitude de faire du C# et de "gros" programmes. (Celui-ci doit faire plus de 1500 lignes, c'est mon premier qui en fait autant, d'ailleurs savez-vous comment afficher le nombre de lignes d'un projet, avec toutes ses classes comprises, à partir de cet IDE ?)

J'ai fait de mon mieux pour être clair alors j'espère que vous comprendrez où je bloque et saurez m'aider.

Merci d'avoir pris le temps de lire mon post !

PS: J'ai envisagé plusieurs fois de faire d'abord mon programme en console, de gérer d'abord juste la communication entre les classes avec des événements (mais même ça je ne sais pas trop comment faire de toute façon..) avant de faire l'interface graphique, j'imagine que c'est le plus judicieux, mais j'avais peur qu'il y ait trop de changements à faire pour repasser en fenêtre après, je ne sais pas trop comment condenser tout le code qui permet "l'interface homme-machine" au même endroit.

bonjour,

Si on part sur une solution à base de winForm, j'aurais tendance à avoir l'approche suivante:

Un UserControl pour représenter un joueur.

Un Usercontrol pour représenter une table...

La table ajoute des Usercontrol joueur quand le nombre de joueur change, etc...

Après, pour commencer basique, t'es user control peuvent juste être composé de controles de bases (bouton, picturebox, label)...

Il faudrait que tu arrives à définir le rendu visuel que tu veux aussi pour s'en rapprocher au bout d'un moment...

D'accord, je vais me renseigner sur les UserControl, je vais suivre ce tuto : http://morpheus.developpez.com/usercontrols/

Par contre pour faire communiquer les classes entre elles je ne vois vraiment pas comment faire ? Faut-il que je change des choses sur la visibilité/l'imbrication des classes ?

si tu veux un truc joli wpf est peut etre plus adapté
wpf oblige presque à séparer le code métier (jeu dans ton cas ^^) du code l'interface, ce que ne fait pas trop windows forms
donc si tu as déjà du code qui ne gère pas d'interface tu peux partir sur wpf je pense
il y aurait juste un peu de code à rajouter dans celui ci

en windows forms on travaille beaucoup avec les events des controles
en wpf, on définit comment se dessine graphiquement une classe en gros, ou dire qu'un bouton appelle une méthode de l'instance qu'il est en train d'afficher, le tout avec du binding
binder un controle à une propriété (genre maxseats) c'est bien, mais après il faut aussi l'inverse (que la modification de listeactionpossible d'un joueur fasse apparaitre les boutons par exemple)
pour ca il faut que le code de base gère le fait d'avertir l'interface, pour ca le plus simple est d'implémenter INotifyPropertyChanged dans tes classes, et lever l'event qui va avec dans chaque propriété
ce qui fait que sur le control joueur tu afficheras l'équivalent d'un itemscontrols (listbox sans sélection) qui aura un bouton par action possible, si aucune action possible rien ne sera affiché
quand listeactionpossible changera sur une instance de joueur l'interface sera mise à jour automatiquement sans taper de code (grace à INotify... que wpf gère)

et il faudra des classes intermédiaires (ne serait ce que pour gérer le positionnement des joueurs)

néanmoins ca serait quand même plus simple à coder en windows forms, mais wpf ressemble plus à l'avenir (vs >= 2012 pour faire du wpf, c'est mieux)
pour wpf se renseigner sur les 4 types de panels existants, le binding (et les converters), datacontext qui est pratique dans la plupart des cas, les datatemplate, et le MVVM

Wow, merci beaucoup pour cette réponse très précise.
Cependant pourquoi utiliser wpf si c'est plus dur ? Pour prendre de bonnes habitudes de programmation de GUI ? C'est vrai que cette fonction de binding a l'air incroyablement puissante, je comprends déjà comment ça marche.
Si jamais je décide d'utiliser windows forms, quelles sont les classes/interfaces dont je pourrais avoir besoin spécifiquement ?

pourquoi faire du c# alors que quick basic de 1980 (environ) est plus simple ? :D

windows forms c'est une techno d'affichage qui date de windows 95, légèrement amélioré avec gdi+ peu après (98 ?)
chaque control a un handle de form de windows, chaque controle se redessine tout le temps (enfin juste trop souvent à mon gout ^^)
la transparence existe mais c'est un bricolage, donc dans certains cas ça ne fonctionne pas et on comprend le bricolage derrière
tout est rectangle
etc...

wpf ca date de 2008, ca commence à être utilisable sans trop galérer depuis vs 2012 (même si je trouve que ca manque de certaines choses)
c'est une techologie d'affichage entièrement vectorielle, qui gère aussi un peu de 3d si nécessaire
tout a la forme qu'on veut (un bouton triangle ou d'une forme très complexe est faisable)
la transparence est bien gérée
l'affichage se fait via directX donc utilise certaines capacités de la carte graphique (winforms processeur seulement)
et on a un langage descriptif d'interface et de lien avec les données (xaml) qui est plutot lisible (basé sur l'xml)
on début on pose encore les controles sur les windows comme on en a l'habitude avec winform ou autre, puis rapidement on écrit ce qu'on veut, c'est beaucoup rapide dans la précision (car le placement des controles est vraiment agréable à utiliser)
et autre avantage moins visible, wpf utilise beaucoup moins de classes non managées (control, graphics, bitmap pour windows forms) donc y a moins de chose à penser à disposer (IDisposable)
dernier avantage, en winforms quand ton appli est finie et que tu veux changer le design tu pleures (ou tu te pends si ton chef veut vraiment que tu le fasses ^^)
en wpf tu rajoutes quelques lignes de xaml pour préciser l'affichage par défaut (affichage, forme, couleur, comportement ...) de chaque controle dans application.xaml et c'est réglé (controltemplate, style)

c'est plus dur surtout parce que c'est plus complet et sur une approche différente
et il a aussi des inconvénients (enfin n'étant pas allé au bout je ne peux dire que telle chose est nulle car j'ai peut-être juste raté un truc)

après si tu pars sur windows forms, il n'y a pas d'interface vraiment utile, les bindings existent aussi (et dans ce nécessitent aussi INotify...) mais sont beaucoup moins puissants (pas de bouton qui appelle une ICommand)
après tout se code, si tu veux du binding aussi puissant en winform tu peux le coder toi même, c'est l'avantage de .net, c'est que tu peux te rajouter plein de choses, y compris dans l'exécution de visual studio
et donc il faudrait gérer les events de tes controles, et les events de tes classes de jeu
sur l'event combobox de selection de nombre de joueur : changer la variable nombre de joueur, appeler la méthode qui s'occupe du placement des joueurs (et donc des controles qui vont avec)
sur l'event de la classe de jeu qui dit que les actions possibles d'un joueur change, il faudrait que tu retires/caches ou réaffiche le panel de controle, sur l'event d'un bouton rappeler la méthode qui gère le bouton
...

Je m'exprime maladroitement des fois, je me demandais effectivement les avantages du wpf par rapport au windows forms. :D
J'irais donc apprendre à utiliser wpf quand j'aurais le temps, je pense que c'est un meilleur investissement à long terme, même si ça me prendra plus de temps à perfectionner que windows forms.

Merci beaucoup pour tes réponses très détaillées, et bonne soirée à toi !

WPF n'est pas un meilleur investissement, j'ai juste une techno différente comme décrite très justement par Pol63.

Je trouve qu'avec winform, on va un peu plus vite pour du prototypage grossier...

Après, WPF offre des mécanismes de binding, routage d'event très puissant et donc très utile...

Pas sur que dans ton cas, en dehors de l'aspect Graphique de WPF, tu l'utilises plus que ça.

Par contre, moi, quand WPF est arrivé (je suis plutôt "pro" winforms), j'ai eu envie de fortement découper le dev entre : Dev==> développeur, graphique/IHM==>infographiste.

Perso, je suis nul en dessin et n'est aucun sens artistique et pour faire du beau avec WPF, il faut aimer parfois jouer un peu à "photoshop like"... moi, ça me saoule...

Ceci dit, WPF est vraiment puissant pour facilement adapter son IHM (vu que le rendu est dédié à des classes qui utilises XAML..)

Je vais également te recommander WPF puisque WinForms est très limité sur le plan graphique (si tu veux sortir des boutons gris et moches à la Windows 95 ça demande beaucoup trop de boulot).

Maintenant WPF est beaucoup plus casse-c... à programmer que WinForms : l'idée de base est excellente, la mise en oeuvre est médiocre. Ça a ses avantages une fois que tu as une bonne expérience, ça finit peut-être même par devenir une meilleure solution une fois que tu as rajouté 50k lignes de code perso pour faire la plomberie pour faire une appli de taille, mais enfin... Non pas que WinForms soit une bonne solution, simplement que pour faire de WPF ce qu'il promettait d'être il manque beaucoup de choses qui, aujourd'hui, sont dispos en Javascript. Bref, oui, tu vas galérer. Mais WinForms est tellement moche...



Bon, à part ça, l'essentiel est que tu comprennes MVVM (*). Petit exemple :
* Tu définis ton interface en XAML et à un moment tu auras par exemple un contrôle avec "Foreground = {MoneyColor}". Ce code XAML forme ta vue (V) et Foreground est une propriété de chaque contrôle. MoneyColor se réfère à ton VM.

* Puis tu définis donc une classe PlayerVM qui implémente INotifyPropertyChanged avec une propriété MoneyColor. C'est ton modèle de vue (VM) : c'est lui qui sera passé en DataContext. Il informe la vue de l'état à adopter en fonction de l'état du modèle.

* Enfin tu as une classe Player qui n'implémente PAS InotifyPropertyChanged, et qui n'a pas de propriété MoneyColor puisque c'est une propriété de la vue. En revanche il a sans doute une propriété Money. Player appartient au modèle (M).

(*) Gaffe, le web est plein d'âneries sur WPF et MVVM : la faute à MS qui prodiguait initialement de mauvais conseils car ils n'avaient pas eux-mêmes expérimenté leur produit.



Donc maintenant la difficulté pour toi c'est de trouver comme lever l'événement OnPropertyChanged. Deux approches possibles pour le VM :

Code:

---

1 2 3 4 5 6 7 8 9

public int Money { get { return _money; } set { _money = value; OnPropertyChanged("Money"); OnPropertyChanged("MoneyVM"); } }   public Brush MoneyColor{ get { if (_money < 0) return Red; else return Blue; } }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public intMoney { get { return _money; } set { __money = value; OnPropertyChanged("Money"); if (_money < 0) MoneyColor = Red; else MoneyColor = Blue;} }   public Brush MoneyColor { get { return _moneyColor; } set { _moneyColor = value; OnPropertyChanged("MoneyVM"); } }

---

Citation:

---

Envoyé par Knightdead

Cette année je suis en maths sup, l'info qu'on fait est assez théorique, avec des langages de haut niveau alors j'ai rien appris ni sur les interfaces graphiques ni sur le C# et je ne suis pas avancé.

---

Petite précision : C# est considéré comme un langage de haut-niveau (encore qu'il l'est sans doute de moins en moins au fur et à mesure que des langages de plus haut niveau apparaissent).

Ce que toi tu fais en maths sup ce sont sans doute des langages fonctionnels, soit Haskell (ce serait vache pour vous), soit quelque chose à la sauce ML (OCaml par ex), voire Lisp. Mais ces langages sont peu utilisés en-dehors des milieux académiques. Probablement parce qu'ils sont faits pour ressembler aux mathématiques (proximité du domaine des utilisateurs), insistent sur la cohérence théorique sous-jacente (correspondance de Curry-Howard, types algébriques, bigint par défaut) et se focalisent en général sur la liberté d'expérimentation avec le langage (un chercheur doit pouvoir le modifier). Tandis que les langages industriels se focalisent plutôt sur la consolidation de l'écosystème via une certaine rigidité, sur la facilité de recrutement et de relecture, et le mode impératif est souvent plus proche de nos modes de pensée que le mode fonctionnel (proximité du domaine des utilisateurs).

Encore que certains ML se défendent bien en entreprise, F# par exemple. Ainsi que dans les domaines où la concurrence est massive et les états à proscrire. Et par ailleurs les expérimentations menées dans les langages académiques finissent régulièrement par irriguer les langages industriels, sous une forme différente.

Citation:

---

J'ai l'impression que la plupart de mes problèmes viennent du fait qu'il faut que j'utilise massivement les événements alors que je ne les maîtrise pas du tout

---

Les événements ne sont utilisés que pour la communication entre la vue et le VM (avec quelques exceptions comme la réaction à un clic), presque exclusivement via INotifyPropertyChanged. Pas entre le modèle et le VM.

Par exemple mettons que tu cliques pour miser.
* En XAML tu vas spécifier le nom d'une méthode à invoquer en réaction à un clic, cette méthode appartiendra à la vue. MainPage.OnWageClick.
* Ce code va alors invoquer PlayerVM.Wage(amount). PlayerVM va alors modifier l'argent de Player et le tas, mais il va aussi mettre à jour ses propres propriétés (Money, MoneyColor, etc) en signalant à l'UI qu'elles ont changées.
* Puis l'UI se mettra à jour en réaction aux événements lancés par la VM.

Bon, en pratique les choses peuvent être un peu différentes car tu as plusieurs objets qui entrent en jeu (le joueur et le tas, et peut-être un troisième stockant la mise - ou pas) et je n'ai pas réfléchi au problème, à qui devait orchestrer l'ensemble.

Citation:

---

Envoyé par DonQuiche

Petite précision : C# est considéré comme un langage de haut-niveau (encore qu'il l'est sans doute de moins en moins au fur et à mesure que des langages de plus haut niveau apparaissent).

Ce que toi tu fais en maths sup ce sont sans doute des langages fonctionnels

---

En info commun on fait du Python, d'où le fait que je ne considère pas trop C# comme un langage de haut-niveau (bon j'ai déjà fait un peu de C et un peu d'assembleur et c'est vrai que ça n'a rien à voir xD), mais plutôt intermédiaire. En option info on fait du Caml Light, donc ouais grosso modo du OCaml.


Mais du coup j'hésite toujours légèrement entre les deux, je me déciderai plus tard. Le programme que je vais faire est simplement pour moi et ça ne me dérange pas qu'il soit moche, mais mon expérience en WPF pourrait me faire gagner du temps plus tard si je veux distribuer un programme, je voudrais bien sûr qu'il ne soit pas moche, du coup...
En tout cas j'ai bien compris les avantages et inconvénients des deux, et je pense plutôt opter pour WPF, de toute façon j'ai le temps d'apprendre à m'en servir, l'été approche. :)

Merci beaucoup DonQuiche pour tes conseils, ça me sera très utile !