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