Dans le tutoriel précédent nous avons vu l'utilité des ENUMERATIONS pour rendre notre code plus lisible et plus sûr, et profiter des automatismes de code proposés par l'éditeur de code du WLangage. J'ai aussi rapidement évoqué en fin de tutoriel qu'une variable de type énumération ne pouvait stocker qu'une valeur à la fois. Autrement dit, pour reprendre les mêmes exemples, je remets la capture du tuto précédent dur les énumérations : La limite ici, c'est que si MaBalle est une BALLE_TRAVERSANTE, alors elle ne peut pas être en même temps une BALLE_RAPIDE. Bien sûr ici, c'est tout à fait le comportement attendu, et ça correspond parfaitement à la logique voulue dans mon jeu de casse brique, et c'est même pourquoi j'ai choisi une énumération. Quelques changements de logique au programme : Mais changeons la logique du jeu. Je veux désormais que ma balle comporte plusieurs caractéristiques à la fois, et que le tout soit stocké dans une seule variable. Deuxième changement : jusqu'ici j'ai défini MaBalle comme une énumération directement, mais il serait plus correct de reprendre la structure Objet du jeu (Voir TUTO PHASE , et donc avoir une propriété dédiée de l'objet pour gérer les caractéristiques, par exemple un objet de classe CBalle ayant des Capacités, pour avoir MaBalle.Capacités = . Qu'est ce qu'une Combinaison ? Une COMBINAISON, c'est une variable que l'on remplirait comme un panier, avec les différents ingrédients qui nous intéressent. Contrairement aux énumérations, on peut avoir plusieurs choses à la fois dans son panier. Si l'on transpose la logique à ma balle, on peut considérer qu'elle puisse à la fois être une BALLE_TRAVERSANTE, une BALLE_RAPIDE, mais rien ne l'empêche aussi d'être en même temps une BALLE_FOURBE, ce qui en démultiplie les variations possibles. Redéfinissons donc notre début de classe CBalle, telle qu'elle était codée dans le tutoriel du Casse Briques (Voir TUTO PHASE , lisez donc bien les commentaires de code : Voilà donc notre BALLE dotée de capacités multiples ! Créons quelques objets basés sur ce modèle, par exemple au même endroit où dans notre jeu on avait défini notre tableau de 100 Baballes (dans la Déclaration globale de la fenêtre FEN_Baballe) : Tiens premier constat magique , windev a compris que c'était une Combinaison de plusieurs possibilités inclusives et me propose donc de cocher les choix directement sans avoir à les coder !!! Vous avez surement déjà vu apparaître cet assistant dans des fonctions du WLangage, mais vous ignoriez peut-être jusqu'ici que vous pouviez aussi en bénéficier dans vos propres conceptions. Deuxième constat, lorsque j'appuie sur la touche [ENTREE] du clavier la liste se transforme en addition : C'est donc comme cela qu'on peut ajouter ou retrancher diverses caractéristiques à une seule variable. Ce code marcherait d'emblée si notre COMBINAISON était définie ailleurs que dans notre classe. Malheureusement, comme j'ai défini ma COMBINAISON dans le code de ma CLASSE, elle n'est pas visible d'elle même depuis l'extérieur de l'objet. (Je viens de soumettre à PCSOFT qu'il serait bien d'améliorer ce point). C'est pour ça qu'elle affiche une erreur. Dans ce cas de figure précis, pour corriger notre code, il faut donc faire précéder chaque élément de la combinaison par le nom de la classe, suivi de "::", avec la syntaxe un peu lourde suivante donc : Note : Il est tout de même conseillé qu'une classe dépende le moins possible d'éléments extérieurs à elle même, si bien que puisque mes énumérations et combinaisons ne concernent que cette classe, il vaut tout de même mieux les définir sur la même page de code, au dessus donc de la définition de la classe, comme dans la déclaration CBalle telle qu'elle apparaît ci dessus (2ieme capture d'écran) . Et tant pis si c'est lourd d'avoir à ajouter CBalle:: , en attendant que PCSOFT n'améliore la chose. Allez quelques petits essais, pour ajouter, modifier, supprimer, ou tester les caractéristiques de nos balles, pour vous montrer comment on manipule ces choses là : RAPPEL : le préfixe CBalle:: ne sera pas nécessaire si vous avez défini votre Combinaison ailleurs que dans le code de la classe. Par exemple dans le code de Déclaration d'une collection de procédures globales. Prenons un autre exemple, cette fois en dehors d'une classe, juste dans une utilisation plus classique sur une variable de type combinaison : On retrouve ici une implémentation proche de l'exemple des jours ouvrables que nous avions étudié dans le tutoriel sur les Enumérations, à la différence que nous pouvons désormais "cocher" plusieurs jours à la fois, dans notre variable, grâce aux combinaisons, ce qui s'avère dans ce contexte beaucoup plus pertinent (une entreprise peut en général livrer ou être livrée plusieurs fois dans une semaine). Terminons par l'intégration des combinaisons à des procédures, à la suite du code précédent j'ajoute ce qui se trouve dans l'encart rouge : C'est encore plus simple à utiliser de cette manière, surtout qu'on récupère les automatismes des listes à coches de windev. On ne peut pas se tromper, et toujours cocher plusieurs choix. De même, vous pouvez aussi retourner une Combinaison comme valeur de retour. Il est à noter que dans les classes, on évite en général d'accéder directement en lecture ou en écriture aux variables. On utilise de préférence un mécanisme de définition de propriétés qui consistent à protéger la variable qui stocke la valeur à l'intérieur de la classe. Il est donc utile parfois de recourir à des méthodes de classe qui fournissent indirectement la donnée, ou qui en changent la valeur. (On appelle communément ces méthodes des Getters et des Setters, qu'on pourrait traduire en français par des Méthodes de Lecture et des Méthodes d'écriture). C'est souvent dans ce contexte qu'on utilise ce genre de tournure de procédures qui renvoient des types complexes, ou les prennent en paramètre. Nous quittons un peu le sujet des Combinaisons, mais c'est juste pour vous démontrer comment cela peut s'intégrer à la POO, et donc aux autres tutoriels autour du Casse Briques. Maintenant à vous de jouer. Créez vos propres Combinaisons et/ou émumérations pour votre logique métier, c'est vraiment plus lisible et plus sécurisé que d'utiliser des chaines ou des entiers pour stocker des valeurs, car même en revenant des mois après sur vote code, il n'y aura aucune ambiguïté à le relecture et donc aucun nouveau bug lié à l'oubli. Source : Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!