|
Une remarque pertinente ? Une critique impertinente ? Un lynchage en règle ? Une invitation sous les tropiques ?  Ecrivez-moi ! |
 |
||||
|
Conçu et enseigné tel qu'en lui même, avec pertes, fracas et
humour de qualité supérieure par Christophe Darmangeat dans le M2 PISE du Master SSAMECI (Université Paris 7) |
|||||
 |
|||||
|
Partie 1
VB.NET, un langage objet
1. C'est quoi, un langage objet ?
Vous le savez sans doute déjà : VB.NET est un langage objet. Ce n'est
pas le seul : C# (prononcez "cécharpe"), C++ ou Java sont eux aussi des
langages objets. Ce type de langage, apparu dans les années 1990,
s'oppose en particulier aux langages de la génération précédente, qui étaient
dits "procéduraux" (comme le Cobol, le Fortran, le Pascal, le C et bien
d'autres, on ne va pas tous les citer, on n'a pas que cela à faire non
plus).
La première chose à dire des langages objet, c'est qu'ils permettent de
faire tout, absolument tout, ce qu'on pouvait faire avec un langage
procédural.
Donc, et c'est la bonne nouvelle du jour, rien de ce que vous avez
appris n'est perdu ! Les langages objet, comme leurs ancêtres les
langages procéduraux, manipulent des variables, des tableaux et des
structures, et organisent des instructions d'affectation,
d'entrée-sortie, de tests ou de boucles dans des procédures et des
fonctions. Donc, à la limite, on peut (presque) programmer en langage
objet comme on programmait en langage procédural. Mais évidemment, dans
ce cas, on passe à côté de ces petits riens que les langages objet
possèdent en plus, petits riens qui vont nous changer la vie...
Remarque sournoise :S'il y a quelque chose que vous ne comprenez pas dans le paragraphe qui précède, c'est vraisemblablement que vous avez doublement brûlé les étapes. D'une part, en voulant apprendre VB.NET sans avoir appris l'algorithmique. D'autre part, en n'ayant pas lu assez attentivement les Préambules nécessaires (ce qui n'est pas bien) ou en les ayant lu, et en choisissant de les ignorer (ce qui est encore pire). Dans les deux cas, vous n'échapperez pas à un retour par la case départ, et vous ne touchez pas 20 000 F.
Reprenons. Les langages objet, tout en intégrant l'ensemble des
capacités des langages procéduraux, possèdent deux aptitudes
supplémentaires, aptitudes liées mais distinctes. Ces langages peuvent
en effet :
On verra plus tard que par contamination, les
langages objet ont tendance à tout assimiler à des objets, même des
choses qui n'en sont pas spécialement, comme les bonnes vieilles
variables de notre enfance. Mais n'anticipons pas, et examinons tout
d'abord les deux points ci-dessus plus en détail.
1.1 Qu'est-ce qu'un objet ? Parlons comme les gens normaux Dans la vie de tous les jours, nous sommes entourés d'objets.
Certains très simples, comme un peigne, un bouton de culotte ou une
matraque de CRS. D'autres très complexes comme une automobile, un
ordinateur ou une
navette spatiale. Pour faire l'analogie avec les objets des langages
objet, mieux vaut penser à un objet un peu compliqué qu'à un objet trop
simple. Et pour cette analogie, rien ne nous oblige à penser à un objet
inanimé. Des plantes, des animaux ou des êtres humains peuvent tout à
fait être assimilés aux objets que manipulent les langages.
Dans les objets, il y a deux sortes de choses qui intéressent les
informaticiens.
Tous les objets possédant les mêmes caractéristiques et avec lesquels
on peut faire les même choses forment un groupe qu'on appelle en
informatique une classe.
Par exemple, tous les chiens, et c'est à cela qu'on les reconnaît, ont une couleur de
pelage, une taille, un poids, etc. Ils peuvent tous aboyer, courir,
sauter, etc. Même si chacune de ces aptitudes est différente d'un
chien à l'autre, et même si le chihuahua de ma cousine est assez
différent du rottweiler de mon voisin, ces deux bestioles ont en commun
de posséder certaines caractéristiques et de pouvoir effectuer certaines
actions. Ils font donc partie d'une classe unique que j'appelle "les
chiens", même si d'un chien à l'autre, et ma cousine en sait quelque
chose lorsqu'elle croise mon voisin, la taille et le poids (entre
autres) ne sont pas les mêmes.
En prenant le problème à l'envers : si je définis une classe par
l'ensemble de ses caractéristiques et de ses actions, je peux, à partir
de cette classe, fabriquer tout plein de toutous différents les uns des
autres, mais qui auront en commun d'être tous des chiens (donc,
répétons-le lourdement, des êtres qui partageront les mêmes caractéristiques et qui
seront capables des mêmes actions).
Eh bien, les langages objet, ce sont des langages qui permettent, en
plus des traditionnels variables, tableaux et structures, de gérer et de
manipuler des objets (donc des classes). C'est-à-dire que ces langages
permettent notamment :
Tout ce que nous avons vu là peut être traduit dans des termes
techniques propres aux informaticiens.
1.2 Qu'est-ce qu'un objet ? Parlons comme les informaticiens Nous savons que tout programme informatique a pour but de manipuler
des informations. Et nous savons que ces informations relèvent toujours, au
bout du compte, de l'un des trois grands types simples : numériques, caractères
(alphanumériques), ou booléennes.
Lorsque nous disons qu'un objet (ou une classe) possède des
caractéristiques comme la taille, le poids, la couleur, etc., nous
disons en fait qu'un objet (ou une classe) regroupe un certain nombre de
variables : une variable numérique pour stocker le poids, une autre
variable pour stocker la taille, une variable caractère pour stocker la
couleur, etc.
Donc, première chose, un objet regroupe un ensemble de variables qui
peuvent être de différents types. Et dans ce cas, on ne parlera pas des
"variables" d'un objet, ni des ses "caractéristiques", mais de ses
propriétés (ou encore, de ses attributs).
 Définition :
Une propriété d'un objet est une des variables (typée) associées à cet objet. Théorème :
Par conséquent, toute instruction légitime avec une variable est légitime avec une propriété d'un objet. Et lycée de Versailles, tout ce qui n'avait pas de sens avec une variable n'a pas non plus de sens avec une propriété d'un objet. Jusqu'à maintenant, allez vous dire, nous n'avons fait que faire de
la mousse avec du vocabulaire nouveau autour d'une notion que nous
connaissons déjà comme notre poche. Parce qu'enfin, quoi, un bidule
constitué de différentes variables de différents types, on n'a pas
attendu les objets pour en avoir. Tous les langages procéduraux
connaissent cela, mis à part qu'on ne parle pas de classe mais de
structure, qu'on ne parle pas d'objets, mais de variables structurées,
et qu'on ne parle pas de propriétés, mais de champs. Mais pour le reste,
c'est tutti quanti et du pareil au même.
Les esprits chagrins qui feraient cette remarque auraient parfaitement
raison... si les objets n'étaient effectivement qu'un ensemble de caractéristiques (de propriétés).
Mais les objets, comme nous l'avons vu, ne sont pas que cela : ils
incluent également, comme on l'a vu, des actions possibles. Autrement
dit, un objet (une classe) est un assemblage d'informations (les
propriétés) mais aussi d'instructions (les actions, que l'on appelle les
méthodes). C'est en particulier cette présence des méthodes qui différencie une
classe d'une simple structure, et un objet d'une simple variable
structurée.
Définition :
Une méthode est un ensemble d'instructions (de lignes de codes) associées à un objet. Mais ce n'est pas le seul point. Nous y reviendrons, les objets peuvent aussi être associés à ce que l'on appelle des événements, événements qui joueront un rôle essentiel dans le déroulement de notre application.
Théorème :Un objet est un assemblage d'informations et d'instructions. Autrement dit, c'est une variable structurée plus des méthodes et des événements. 
2. La syntaxe objet 2.1 Généralités
Lorsque nous fabriquions (et nous en fabriquerons encore) une variable,
nous utilisions un moule à variable, qui s'appelait un type. Pour créer
une nouvelle variable, il fallait lui donner un nom, par lequel on
pourrait la désigner tout au long du programme, et préciser le type
utilisé pour la fabrication de cette variable. D'où la syntaxe du genre :
Dim Toto as Integer
Eh bien, en ce qui concerne les objets, le principe est exactement le
même, hormis qu'on ne les fabrique pas avec un type, mais avec une
classe. Si nous disposons par exemple d'une classe Chien, nous allons
pouvoir créer autant de chiens que nous voulons. Voilà par exemple un
nouveau compagnon :
Dim Rex as New Chien
On remarque la présence du mot clé New, propre aux déclarations
d'objets, et qui différencie celles-ci des déclarations de variables.
Dans le jargon du langage objet, cette instruction New s'appelle un
constructeur.
Vocabulaire savant : Créer un objet d'après une classe s'appelle instancier la classe. Un objet peut aussi être appelé une instance, ou une occurrence, de la classe. Notre classe Chien a forcément été créée avec un certain nombre de
propriétés et de méthodes. Nous pourrons accéder à ces propriétés et à
ces méthodes par la syntaxe suivante, universelle :
NomdObjet.Propriété
Et également :
NomdObjet.Méthode
Remarque fondamentale :Dans un langage objet, on ne peut trouver que les deux syntaxes ci-dessus. Il est absolument impossible de désigner un objet sans le faire suivre d'une propriété ou d'une méthode. C'est une faute de syntaxe. De même, une propriété seule ou une méthode seule constituent également des fautes de syntaxe. 2.2 Propriétés Admettons pour les besoins de la cause que notre classe
Chien possède
entre autres propriétés :
Alors, je le rappelle, les règles d'utilisation de ces propriétés
sont très exactement les mêmes que celles des variables. Sachant que le
signe d'affectation, en Visual Basic, est le signe d'égalité, je peux
donc écrire :
Rex.Poids = 14
Et je viens de fixer le poids de mon toutou à 14 kg. Pour le faire
grossir de 5 kg, rien de plus simple :
Rex.Poids = Rex.Poids + 5
...et le tour est joué. Si je veux torturer la pauvre bête, je peux
aussi la rendre aussi lourde que haute, en écrivant :
Rex.Poids = Rex.Taille
L'utilisation de propriétés non numériques ne pose pas davantage de
problèmes :
Rex.Couleur = "Beige"
Rex.Vacciné = True
2.3 Méthodes
Je le rappelle, si les propriétés sont en réalité des variables, les
méthodes sont quant à elles des procédures. Lorsqu'on va utiliser une
méthode, tout dépend donc de la manière dont la procédure a été écrite.
En fait, tout dépend du nombre et du type des paramètres dont cette
procédure a besoin pour s'exécuter. Ainsi, certaines méthodes
peuvent-elles être utilisées sans passer de paramètres. D'autres en
exigeront un, d'autres deux, etc.
Dans tous les cas, cependant, une méthode est un appel de procédure.
C'est donc une instruction à part entière. Nous en déduisons donc
qu'il serait parfaitement
absurde d'affecter une méthode, comme on affecte une propriété. On
pourra donc avoir des lignes du genre :
Rex.Aboyer
ou
Rex.Courir(15)
ou
Rex.DonnerlaPapatte("gauche")
etc.
Si vous avez compris cela, vous avez compris
45 % de ce cours. Très exactement, au millipoil près.
3. La programmation événementielle Nous ne sommes pas au bout de nos peines (ni au bout de nos joies). Toute
cette sombre histoire d'objets cache une autre drôle de plaisanterie,
qui va radicalement transformer la manière dont les procédures d'un
programme vont être exécutées, et du coup, la manière dont les
programmeurs vont devoir concevoir leurs applications.
C'est le deuxième aspect dont je parlais au début de
ce chapitre,
aspect qui est lié à la programmation objet, mais qui ne se confond
pas tout à fait avec elle. De quoi s'agit-il ?
Rappelons-nous comment
notre code était organisé dans un langage procédural traditionnel. Plutôt qu'une immense procédure fait-tout,
comportant des redites de code, nos applications, dès lors qu'elles
devenaient un peu joufflues, étaient organisées en modules séparés :
sous-procédures et fonctions (lesquelles, je le rappelle, ne sont jamais
qu'un cas particulier de sous-procédures).
Parmi ces diverses procédures, il s'en trouvait une
qui jouait un rôle particulier : la
procédure principale (appelée Main dans la plupart des langages). C'est
elle qui était exécutée lors du lancement de l'application. Et c'est
elle qui tout au long du programme, telle un chef d'orchestre,
déclenchait les autres procédures et les autres fonctions.
Le point important dans cette affaire, c'est qu'une fois
l'application lancée, une procédure donnée ne pouvait s'exécuter que si
une ligne de code, quelque part, en commandait le déclenchement.
L'utilisateur n'avait aucune espèce de moyen d'influencer directement
l'ordre dans lequel les procédures allaient être exécutées.
Tout ceci va être remis en question avec les langages objet. Non
qu'on ne puisse plus créer encore des procédures et des fonctions, et
appeler les unes via les autres par des instructions adéquates ; je le
rappelle, il n'y a rien qu'on pouvait faire avec un langage procédural
qu'on ne puisse faire avec un langage objet. Mais avec un langage objet,
on va pouvoir faire certaines choses véritablement inédites. En
l'occurrence, la grande nouveauté, c'est qu'on va pouvoir organiser le
déclenchement automatique de certaines procédures en réponse à certaines
actions de l'utilisateur sur certains objets. Et ces actions, ce
sont les fameux événements dont je parlais tout à l'heure.
Pour comprendre cela, le plus simple est de penser que certains
objets ont une caractéristique particulière : ils se voient à l'écran.
Ainsi, un logiciel comme Windows est en fait truffé de ce genre d'objets
! Les boutons, les menus, les fenêtres, les cases à cocher, tout cela
constitue une armada d'objets visibles, et surtout, capables de réagir à
diverses sollicitations de l'utilisateur via le clavier ou la souris.
Les programmeurs qui ont écrit Windows ont donc prévu, et écrit, des
myriades de morceaux de code (des procédures) qui se déclenchent à
chaque fois que l'utilisateur accomplit telle action sur tel type
d'objet. Donc, je le répète, concevoir une application événementielle,
c'est concevoir des procédures qui se
déclencheront automatiquement à chaque fois que l'utilisateur
effectuera telle action sur tel objet qu'on aura mis à sa disposition.
Remarque
profonde :Dans les phrases qui précèdent, les mots "à chaque fois que" sont essentiels. Il faut impérativement les avoir en tête lorsqu'on écrit une application objet. Faute de quoi on mélange tout, et en particulier, on se met à écrire des boucles là où il n'y a qu'une simple procédure. Définition :Une action sur un objet capable de déclencher une procédure s'appelle un événement. Voilà pourquoi ce type de programmation porte le nom
de programmation événementielle. Par ailleurs,
je rappelle que les événements qu'un objet donné est capable de
gérer ont été définis dans la classe qui a servi à créer l'objet.
Remarque importante :Tous les objets capables de gérer un événement ne sont pas forcément des objets visibles à l'écran. Dans le même ordre d'idées, tous les événements ne correspondent pas forcément à des actions de l'utilisateur via le clavier ou la souris. Mais pour commencer, on peut très bien s'accommoder de ces approximations. 3.1 Le diagramme T.O.E. Lors de la conception d'un programme objet, une des premières tâches
du développeur va donc être de concevoir l'interface utilisateur.
C'est-à-dire de prévoir quels objets vont être mis à la disposition de
l'utilisateur, de prévoir les actions que l'utilisateur pourra effectuer
sur ces objets (les événements) et de prévoir les tâches que le
programme devra accomplir lors de ces événements.
Remarque incidente :
Pour le moment, nous nous contenterons de considérer que nos applications emploient uniquement l'arsenal des objets utilisés par Windows. Ces objets (plus exactement, ces classes) seront donc tout prêts à l'emploi. Leurs propriétés, leurs méthodes et les événements qu'ils sont capables de gérer ont été définis par Windows, c'est-à-dire par Visual Basic (qui nous sert en quelque sorte d'intermédiaire vis-à-vis de Windows, qui parle un langage trop abscons pour nous). En réalité, dans un programme Visual Basic, on peut utiliser des tas d'autres objets (classes), on peut même en fabriquer soi-même. Nous verrons cela... plus tard. Pour le moment, contentons-nous de la trousse à outils de base que Visual Basic met à notre disposition, et ce sera déjà bien suffisant. Ainsi, nous pouvons prévoir qu'il faudra que la fenêtre de notre
application se présente comme ceci ou comme cela, qu'il devra y avoir
ici un bouton, là des boutons radios, ici une zone de liste, etc. Et
il faut également prévoir qu'un clic sur tel bouton déclenchera tel ou
tel calcul, qu'un choix dans telle liste devra mettre à jour telle ou
telle zone, etc.
Le document synthétique, sous forme de tableau, qui reprend toutes
ces informations, s'appelle un diagramme T.O.E., pour Tâche, Objet,
Événement. C'est un document préalable indispensable à la
programmation d'une application événementielle. Il comporte trois colonnes.
Dans la première, on dresse la liste exhaustive des tâches que doit
accomplir l'application. Dans la seconde, en regard de chaque tâche à accomplir,
on porte, le cas échéant, le nom de l'objet qui en sera chargé. Et dans la troisième,
en regard de chaque objet, on
écrit le cas échéant, mais oui, l'événement
correspondant. Vous l'aviez deviné, décidément vous êtes trop forts.
Remarque importante :
Rien, absolument rien, ne dit qu'un objet doit être associé à un événement et à un seul. Il peut très bien y avoir des objets qui ne gèrent aucun événement. De même, certains objets peuvent très bien être amenés à gérer plusieurs événements différents, qui correspondront donc à autant de procédures différentes. Comment effectue-t-on la liaison entre une procédure et un
événement ? C'est extrêmement simple : cette liaison figure en toutes
lettres dans l'en-tête de la procédure, via le mot-clé
Handles (que
l'on peut traduire par "gère"). Ainsi, une procédure
non événementielle, toute bête, toute simple, que j'appelle Calcul, aura la tête suivante :
Private Sub Calcul()
instructions End Sub Pour que cette procédure s'exécute à chaque fois que l'on clique
sur le bouton nommé Résultat, il suffira que la procédure se présente
ainsi :
Private Sub Calcul() Handles Résultat.Click
instructions End Sub
Si d'aventure, plusieurs événements différents doivent déclencher la même procédure,
ce n'est pas du tout un souci. Il suffit de séparer tous les événements
concernés par des virgules après le mot clé Handles. Si, par exemple la
remise à zéro doit être effectuée en cas de clic sur le bouton Résultat,
mais aussi de clic sur le bouton Annulation, on aura :
Private Sub RemiseAZero() Handles Résultat.Click, Annulation.Click
instructions End Sub
Et voilà le travail.
En réalité, il y a juste une petite subtilité
supplémentaire. C'est que lorsqu'un événement déclenche une procédure,
Visual Basic prévoit automatiquement un passage de paramètres depuis
l'événement jusqu'à la procédure, passage de paramètres sans lequel on
serait parfois bien embêté.
La syntaxe complète d'une procédure événementielle sera donc
typiquement :
Private Sub RemiseAZero(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Résultat.Click, Annulation.Click
instructions End Sub Où, à chaque exécution de la procédure suite à un
événement : :
Gardons ces généralités en tête ; nous aurons naturellement
l'occasion de revenir plus en détail sur ces deux paramètres et la manière de
s'en servir.
Si vous avez compris ce second mécanisme que sont les procédures
événementielles, alors vous avez alors pigé 45 %
supplémentaires du cours. Donc, avec les 45 % précédents, on en est à 90
%. Tout le reste, c'est de la petite bière. Puisque je vous le dis.
|
||||
