La programmation Objet appliquée à .Net par l’exemple Partie 3 sur 3

Navigation globale

Le Binding:

Dans le concept MCV, la vue n’a pour seule vocation d’afficher des données et/ou d’en permettre la saisie. Le binding est un moyen d’afficher ; mettre en forme, convertir (dans les deux sens ou pas) les données entre la couche vue et la couche métier.
Winform est permet pas mal de chose en binding, presque tous les contrôles natifs le permettent.
Par contre, c’est l’essence même de WPF.

Pour que le binding sache qu’une propriété vient de changer de valeur, il est utile (indispensable en WPF) d’implémenter l’interface INotifyPropertyChanged. Celle-ci nous contraint à générer un évènement à chaque changement de valeur, cet évènement passe en paramètre le nom de la propriété concernée.
Le binding va capter cet évènement et automatiquement mettre à jour l’IHM.

Une contrainte concerne les classes partagées, elles ne peuvent pas implémenter d’interface

J’ai déjà écrit un tutoriel sur le sujet, je ne m’étendrai pas plus.

Conclusion:

Le but de ce tutoriel n’était pas de réaliser le jeu en entier.
Cependant les projets (C# et VB.Net) sont conçus pour.
J’ai d’abord réalisé une petite application de test toute simple en Winform.
Le code métier est contenu dans un projet dll.
Cependant, le binding en Winform est limité, principalement au niveau de l’actualisation des listBox.

J’ai donc réalisé un autre programme en WPF, pour celui-ci, Joueur implémente INotifyPropertyChanged et des ObservableCollections ont remplacé les listes.
Dans le xaml, en ressource de la fenêtre est décrit un modèle (Template) qui définit l’affichage d’un Joueur. La collection de Joueurs est bindée à une liste appliquant ce Template.

Vous les trouverez ici.

Ils sont versionnés avec GIT, la branche master est celle décrite tout au long de ce tutoriel. Le développement du code est allé plus loin que ce que montre le tutoriel, chaque étape fait l’objet d’un commit afin de pouvoir suivre les évolutions ou corrections de bugs.

La seconde branche vous donne le départ de l’implémentation dans laquelle les cartes se jouent elles-mêmes. Cette branche n’est pas aboutie, car dans ma logique c’est le joueur qui joue. Mais elle montre que programmer objet c’est d’abord une question de point de vue.

Et s’il vous prend l’envie de réaliser une IHM, le projet (ou la dll) devra être référencé dans votre solution.

VB95 a réalisé une IHM en VB.Net Winform, en modifiant sensiblement mon code à son goût. Vous trouverez son projet ici.
J’en profite pour le remercier de ses nombreuses relectures de ce tutoriel, et de ses encore plus nombreux tests qu’il a réalisés sur le code.

Comme beaucoup de visiteurs de CodeS SourceS, je suis autodidacte (une semaine de stage en 10 ans de C#, ça ne fait pas une formation académique). Ce tutoriel reflète la vision de la programmation objet que j’ai acquise après quelques années de pratique, vision que je souhaitais partager. Elle est forcément imparfaite, elle est probablement incomplète ; alors toute remarque sera prise en considération.

Pour aller plus loin:

Ce document intitulé « La programmation Objet appliquée à .Net par l’exemple Partie 3 sur 3 » issu de CodeS SourceS (codes-sources.commentcamarche.net) est mis à disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixées par la licence, tant que cette note apparaît clairement.