On en arrive à la deuxième grande possibilité supplémentaire des langages objet par rapport aux langages traditionnels.
En PASCAL ou en C, par exemple, une application est constituée d’une procédure principale contenant la totalité du code (y compris par l’appel indirect à des sous-programmes). Les instructions qu’elle contient sont exécutées les unes après les autres, jusqu’à la fin (je passe pudiquement sous silence l’improbable hypothèse d’un arrêt prématuré pour cause d’erreur).
Le point fondamental est que dans un tel langage, l’ordre d’exécution des procédures et des sous-procédures est entièrement fixé d’avance par le programmeur lui-même, par le biais des instructions d’appel des sous-procédures. Par ailleurs, et ce n’est pas un hasard, ces procédures portent des noms arbitraires fixés par le programmeur, hormis le cas particulier de la procédure principale, qui se doit de porter un nom particulier, fixé par le langage (généralement, Main).
Dans un langage objet, on peut, si on le désire, conserver intégralement ce mode de fonctionnement. Mais ce n’est plus le seul possible.
En effet, dans un langage objet, il n’y a donc plus à proprement parler de procédure principale ; en tout cas, l’existence d’une procédure principale n’a rien d’obligatoire.
Chaque procédure est liée à la survenue d’un événement sur un objet, et sera donc automatiquement exécutée lorsque cet événement se produit. Le nom de la procédure est alors, de manière obligatoire, le nom de la combinaison objet-événement qui la déclenche.
On vient de parler des objets, et en particulier des contrôles. Répétons qu’un contrôle est un des éléments de l’interface graphique de Windows, éléments que VB met à la disposition du programmeur pour qu’il constitue ses propres applications. Ainsi, les contrôles les plus fréquents sont : la feuille, le bouton de commande, la liste, la case à cocher, le bouton radio, etc.
Quant aux événements, ils peuvent être déclenchés par l’utilisateur, ou par déroulement du programme lui-même. Les événements déclenchés par l’utilisateur sont typiquement : la frappe au clavier, le clic, le double-clic, le cliquer-glisser. Les événements déclenchés par le code sont des instructions qui modifient, lors de leur exécution, une caractéristique de l’objet ; par exemple, le redimensionnement, le déplacement, etc.
Résumons-nous. Un petit dessin vaut parfois mieux qu’un grand discours :
Le lien entre l'objet, la survenue de l’événement et le déclenchement de la procédure est établi par le nom de la procédure lui-même. Ainsi, le nom d’une procédure événementielle répond à une syntaxe très précise :
Par exemple, la procédure suivante :
Private Sub Machin_Click()
…
End Sub
Se déclenche si et seulement si l’utilisateur clique sur l’objet dont le nom est "Machin". Si on prend le problème dans l’autre sens : si je suis programmeur, et que je veux qu’il se passe ceci et cela lorsque l’utilisateur clique sur le bouton appelé "Go", je dois créer une procédure qui s’appellera obligatoirement Sub Go_Click() et qui contiendra les instructions "ceci" et "cela".
Moralité : Ecrire un programme qui exploite l’interface Windows, c’est avant tout commencer par définir :
quels sont les objets qui figureront à l’écran
ce qui doit se passer lorsque l’utilisateur agit sur ces objets via la souris ou le clavier.
A la différence d’un programme traditionnel, les procédures liées aux différents événements possibles ne seront donc pas toujours exécutées dans le même ordre : tout dépend de ce que fera l’utilisateur.
Mais bien sûr, à l’intérieur de chaque procédure, les règles traditionnelles de programmation restent vraies. C’est déjà ça de pris.
Si vous avez bien compris ce qui précède, vous avez accompli 80 % de la tâche qui vous attend en ce second semestre. Non, ce n’est pas de la démagogie. J’ai bien dit : « si vous avez bien compris ».
Mar 12 Fév - 17:26