Et si je vous disais que toute ce qu'on a fait jusque là n'était qu'une longue introduction ? Que les véritables délices de la programmation objet vous restent encore inconnus ? Que seules les lignes qui suivent pourront vous emporter vers les cimes de la béatitude informatique ? Et que j'ai dû forcer sur la bouteille hier soir pour écrire des choses pareilles ce matin ? Le croiriez-vous ?
En effet, jusqu'à présent, nous n'avons fait qu'apprendre à utiliser des éléments préfabriqués - par d'autres - pour construire nos applications : ces éléments sont les fameux contrôles, que je ne vous présente plus. Cela nous a permis, du point de vue de l'interface, de franchir un pas considérable par rapport à la programmation classique. Ainsi, nous avons découvert la programmation événementielle. C'est déjà bien, me direz-vous.
Certes, vous répondrai-je, car aujourd'hui, j'ai décidé de ne pas être contrariant. Mais réfléchissons un peu plus loin : lorsque nous avons eu des informations à mémoriser ou à traiter, nous avons utilisé les bons vieux outils de la programmation classique : des variables, voire des tableaux ou des variables structurées. Et au pire du pire, des tableaux de variables structurées.
Or, rappelez-vous ce que nous avions vu au tout début de ce cours, lorsque nous avions défini ce que sont les objets : les objets sont, avant toute autre chose, une manière nouvelle de structurer les informations (j'avais employé le terme de "super-variables"). De tout cela, qu'avons nous fait ? En réalité, rien : nous l'avons mis de côté, pour ne nous servir que d'une catégorie particulière d'objets, les contrôles. A peine avons-nous effleuré, pour un besoin précis ou pour un autre, des objets comme App. Autrement dit, même si c'est dur à entendre, il est de mon devoir de vous parler franchement : jusqu'à présent, nous n'avons pas réellement abordé la programmation objet.
Alors, avouez-le, ce serait vraiment trop dommage de se quitter sans remédier à cette grave lacune. Car si les fainéants nous diront que l'humanité a bien vécu quelques millions d'années sans connaître la programmation objet et qu'elle ne s'en est pas portée plus mal, nous leur répondrons sans hésiter qu'avec des raisonnements pareils, on en serait encore à tailler des silex.
Résumons-nous, en regroupant dans un tableau les concepts et le vocabulaire lié à la manipulation des objets et des variables. Rassurez-vous, on reviendra sur tout cela dans pas longtemps :
Variable Objet
contient des informations des informations (les propriétés) et du code (les méthodes)
est désigné par un... nom de variable nom d'objet
le "moule" s'appelle un type ou
une structure une classe
On peut fabriquer ce "moule" dans un module un module de classe
1. 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. Les détracteurs de la méthode objet parlent d'ailleurs volontiers à ce propos d'usine à gaz. Et si l'on jette un oeil sur les ouvrages traitant de la question, on est généralement tenté de leur donner raison, tant le vocabulaire est imperméable à tout être humain normal, et tant les explications fournies fourmillent d'abstractions qui les rendent parfaitement obscures.
Cependant, pour se faire une idée de la chose, on peut aborder la question d'une manière simple, en menant une rapide analyse d'un problème pas trop compliqué. Encore une fois, j'insiste, les lignes qui suivent se veulent être une très brève illustration, et nullement un exposé couvrant tous les recoins de la chose.
Imaginons donc que nous voulions programmer un jeu de Scrabble pour deux joueurs.
Mer 13 Fév - 8:30