Nous n'avons pas réellement abordé la programmation objet. Résumons-nous, en regroupant dans un tableau les concepts et le vocabulaire lié à la manipulation des objets et des variables. 

Mener une analyse objet

Si l'on veut développer une application en raisonnant réellement en termes d'objets, c'est dès le départ, bien avant d'écrire le code, qu'il faut orienter l'analyse dans cette direction.

Mener correctement l'analyse d'un projet complexe en termes objets suppose un savoir-faire extrêmement long à acquérir.

Imaginons donc  que nous voulions programmer un jeu de Scrabble pour deux joueurs.

Analyse classique

Dans une analyse classique, on ferait l'inventaire des données qu'il faudrait coder, et de la manière dont ces codages seraient effectués au mieux.

• Plateau de jeu : pour chaque emplacement du plateau de jeu, on doit savoir s'il s'agit d'une case  simple, ou d'une case avec bonus (mot compte double, lettre compte triple, etc.). On doit également savoir si une lettre y a été posée, et quelle est cette lettre. Une solution simple consiste à créer un tableau de caractères à deux dimensions. On représenterait les cases vides par un chiffre, correspondant à leur valeur : 0 pour une case simple, 1 pour une lettre compte double, 2 pour une lettre compte triple, etc. Lorsqu'une lettre serait posée, on remplacerait dans la case du tableau ce code par la lettre en question.

• Valeur des lettres : un autre aspect à gérer est de mémoriser les valeurs des différentes lettres : au Scrabble, le A vaut 1 point, le B vaut 3 points, etc. Il y a plusieurs moyens de répondre à ce problème. Un d'entre eux consiste à remplir un tableau de 26 nombres, en y mettant, dans l'ordre, les valeurs des lettres. Il suffira ensuite de retrouver que le M est la 13e lettre de l'alphabet, pour aller chercher la treizième valeur de ce tableau.

• Nombre de lettres : toutes les lettres ne sont pas disponibles en quantités égales dans le jeu. Fort heureusement, il y a davantage de E que de W, par exemple. Là aussi, il faudra stocker et mettre à jour cette information, par exemple en tenant à jour un tableau de 26 numériques indiquant les disponibilités restantes pour chaque lettre.

Ces quelques lignes ne représentent bien entendu pas une véritable analyse : elles ne font qu'effleurer l'affaire, mais je les ai écrites pour montrer (en fait, normalement, ce n'est qu'un rappel) quelles questions l'on se pose quand on programme de manière traditionnelle.

Analyse Objet

Passons maintenant à un bref aperçu de la manière dont un programmeur objet se poserait les problèmes. Au scrabble, que fait-on ? On pioche des jetons, qu'on met sur les réglettes des joueurs, puis sur le plateau. Nous devons donc programmer les tribulations de différents objets de type jeton.

Le plateau est formé de cases, qui ont différentes caractéristiques (leur emplacement, leur valeur, le fait qu'elles soient vides ou occupées par des jetons...). Les cases du plateau seront elles aussi des objets maniés dans le jeu Scrabble.

Dès maintenant, remarquons que ce qui entre en compte n'est pas, pour l'essentiel, l'aspect graphique. Certes, on voit les jetons et les cases (encore que, pas toujours, il y a des jetons cachés). Mais ce n'est pas le problème, tout au moins, pas pour l'instant. Ce qui compte, pour parler comme les vrais informaticiens, c'est l'aspect fonctionnel des choses. Ce qui compte, ce sont les "choses" qu'on manipule (j'emploie un mot fourre-tout exprès, car ces "choses" peuvent être tout et n'importe quoi). Mais en l'occurrence, comme souvent, le mieux, c'est de faire simple et direct. Nos objets sont donc des jetons et des cases.

Continuons, en examinant ces objets de plus près.

• Les cases : chaque case se caractérise par sa position sur le plateau (numéro de ligne, numéro de colonne), par son type de bonus, et par son contenu (le jeton qui vient éventuellement l'occuper). Accessoirement, la case se caractérise aussi par un graphisme différent (les "mots compte double" n'ont pas la même tête que les "lettre compte triple").

• Les jetons : chaque jeton du jeu possède une lettre faciale, une valeur, et un emplacement (est-il dans le sac, sur la réglette de tel joueur, ou sur telle case du plateau).

Là aussi, ces quelques lignes sont bien sommaires, et ne font qu'indiquer la direction dans laquelle une analyse complète devrait être menée.

Ce qu'on peut établir dès à présent, c'est que notre jeu manipule deux types d'objets : : le type "cases", et le type "jetons". Toutefois, en bons programmeurs, nous ne parlerons pas de "types" d'objets (ce serait sans doute trop clair) mais de classes d'objets. Nous aurons donc deux classes :

La classe cases, et la classe jeton. Exactement comme nous avons jusqu'à maintenant manié des objets de la classe Bouton de Commande, de la classe Case à Cocher, etc.

Chaque case du plateau, chaque jeton du jeu est donc un représentant de la classe Cases ou de la classe Jeton. Mais là encore, attention Léon : pas question de parler de "représentant", ce serait d'une vulgarité affligeante. L'usage impose le terme fleuri d'instance de classe. Nous dirons donc que les cases individuelles sont des instances de la classe Cases, et que chaque jeton est une instance de la classe Jeton. De la même façon, jusqu'à présent, chaque bouton de commande que nous avons créé était une instance de la classe Boutons de Commande. Ainsi, dans la vie courante, vous saurez dorénavant que chaque gâteau est une instance de la classe Moule à Gâteau. Pensez-y la prochaine fois que vous commanderez quelque chose dans une boulangerie. Effet 100% garanti.

Enfin, chaque caractéristique d'un objet individuel (pour les cases, le numéro de ligne, le numéro de colonne, le type du bonus, etc. ou pour les jetons, la lettre représentée, le nombre de points, l'emplacement dans le jeu) est une propriété de l'objet en question. Mais ce gros mot-là, vous le connaissiez déjà.

Il va de soi qu'en plus des propriétés, nous pourrions éventuellement concevoir des méthodes pour nos objets, c'est-à-dire des traitements en quelque sorte préfabriqués sur leurs propriétés. Quoique dans l'exemple du Scrabble, aucune ne s'impose immédiatement à l'esprit ; on pourrait toujours se forcer pour en inventer, mais franchement, on n'est pas là pour imaginer des difficultés là où il n'y en a pas.

Enfin, une analyse qui serait poussée plus loin devrait également recenser les événements que chaque objet de nos nouvelles classes pourrait recevoir, et les réactions de l'application à ces événements. Là encore, je ne fais que signaler l'existence éventuelle de ce problème, car dans notre exemple, les événements classiques (clic, drag and drop, etc.) devraient largement suffire.

Parvenus à ce stade, on voit qu'en fait, on a recensé peu ou prou les mêmes choses que dans l'analyse classique. Alors pourquoi tout ce barouf ? Parce que nous avons organisé nos idées différemment, et que c'est cette organisation différente qui va nous simplifier la vie au niveau de la programmation (du moins, si l'analyse a été bien menée, que nos classes et nos propriétés sont pertinentes).

La programmation objet ne dispense d'aucune abstraction mentale nécessaire à la programmation traditionnelle. En ce sens, elle ne constitue aucun progrès. Mais elle rend l'écriture de l'application beaucoup plus proche des événements  tels qu'ils se déroulent dans la réalité. Et en cela, elle permet de développer un code beaucoup plus lisible. Le travail en équipe des programmeurs sera donc plus facile à coordonner, et la structure du programme sera plus légère et plus claire. Enfin, si c'est réussi.

Un des paris de la programmation objet, c'est d'alourdir un peu la phase d'analyse, pour gagner beaucoup sur la phase de développement.

Objets et Visual Basic

Mais, si ce n'est que cela, direz-vous, ne serait-ce pas tout bêtement donner un nouveau nom à une vieille marmite ? Car après tout, construire des variables par agglomération de types simples, il y a très longtemps qu'on sait le faire ! Depuis les langages traditionnels et les bonnes vieilles données structurées ! Les objets ne seraient-ils donc pas tout bêtement des données structurées rebaptisées autrement pour être mieux vendues ?

Eh bien non, comme on l'a déjà dit, les objets ne sont pas que cela. Ils sont certes des données structurées. Mais ils sont des données structurées avec deux possibilités supplémentaires, ce qui change complètement la donne.

• Les objets ne sont pas que des propriétés ; il sont aussi des méthodes. Cela veut dire que si dans un langage traditionnel, on sépare les données et les traitements sur ces données, en programmation objet, à l'inverse, on fabrique des bidules (les objets) qui regroupent les données (les propriétés) et les actions sur ces données (les méthodes). Visual Basic, dans la mesure où il fournit le moyen de construire de tels objets, est un langage objet.

• Les objets possèdent une souplesse remarquable, qui se traduit notamment par la notion d'héritage. Je crée une classe "mère", puis des classes "filles" qui héritent de toutes les caractéristiques de la classe mère, plus d'autres, puis des classes petites-filles, qui héritent des caractéristiques de la classe fille, plus d'autres, etc. Ainsi, par exemple, je crée la classe "animal", puis les classes filles "reptile", mammifère", "poisson", etc. qui possèdent toutes les propriétés et méthodes des animaux, plus d'autres spécifiques. Et ensuite, je crée les classes "félin", "canin", "rongeur", etc, qui héritent les propriétés et méthodes des mammifères, en ajoutant des propriétés et méthodes propres et ainsi de suite. Ca ne paraît pas comme ça, mais c'est une manière de procéder très souple et très puissante pour modéliser des données complexes. Or, Visual Basic ne donnant pas le moyen de gérer l'héritage, ce n'est pas un vrai langage objet.

D'où le titre ambigu du titre du premier chapitre de ce cours : "VB, un langage (presque) objet". La boucle est ainsi bouclée, tout est dans tout et réciproquement.