VisualBasic.NET

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 :


gérer, en plus des variables, des choses appelées objets.
exploiter, via certains de ces objets, l'interface graphique de Windows.
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.
ils ont des caractéristiques (une couleur, une taille, un poids, un compte en banque, un nombre de pattes, bref, que sais-je encore). Un objet très simple peut avoir une seule caractéristique (voire aucune, mais là, on peut raisonnablement se demander s'il existe - je laisse cette question aux philosophes désoeuvrés). Un objet complexe peut posséder des centaines, voire des milliers de caractéristiques.
ils peuvent accomplir certaines tâches, ou subir certaines modifications : pour une automobile, on peut ouvrir une porte, démarrer le moteur, freiner, accélérer, etc. Pour un chat, on peut le caresser, le faire marcher, le faire courir, le faire miauler, le faire cuire, etc. Pour un employé, on peut le changer de poste, de qualification, l'augmenter (c'est rare), le licencier (c'est fréquent), etc.
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 :
de créer des classes, en définissant leurs caractéristiques et leurs actions
de fabriquer des objets à partir de ces classes
de manipuler les caractéristiques individuelles de chacun de ces objets, et de leur faire accomplir les actions dont leur classe est capable.
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 :
Taille (numérique)
Poids (numérique)
Couleur (caractère)
Vacciné (booléen)
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 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.
3.2 La syntaxe
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() instructionsEnd 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 instructionsEnd 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 instructionsEnd 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 instructionsEnd Sub
Où, à chaque exécution de la procédure suite à un événement : :
sender est un paramètre en entrée (par valeur) qui désigne l'objet qui a déclenché l'événement
e représente un paramètre en entrée (par valeur) qui spécifie les conditions de l'é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.