Particularités des langages objet
Un langage objet possède toutes les caractéristiques d’un langage traditionnel, avec deux grands aspects supplémentaires.
1), on peut tout à fait programmer dans un langage objet comme on programmerait du Fortran, du Cobol ou du C. Selon le vieil adage, qui peut le plus peut le moins. En pratique, cela voudrait dire négliger tout ce qui fait la spécificité d’un tel langage, comme - entre autres - la prise en charge de l’environnement graphique Windows.
2) un langage objet ne connaît que quatre grands types d’instructions :
- affectations de variables, de différents types
- tests,
- boucles et entrées
- sorties.
Les Objets
La première particularité d’un langage objet est de mettre à votre disposition des objets.
Un objet peut être considéré comme une structure supplémentaire d’information, une espèce de super-variable. En effet, nous savons qu’une variable est un emplacement en mémoire vive, caractérisé par une adresse – un nom – et un type (entier, réel, caractère, booléen, etc.). Dans une variable, on ne peut entreposer qu’une information et une seule.
Un objet est un groupe de variables de différents types. Il rassemble ainsi couramment des dizaines d’informations très différentes les unes des autres au sein d’une même structure, rendant ainsi ces informations plus faciles à manier.
Les différentes variables d’un même objet ne sont pas désignées par un indice, mais par un nom qui leur est propre. En l’occurrence, ces noms qui caractérisent les différentes variables au sein d’un objet s’appellent des propriétés de l’objet. Conséquence, toute propriété d’objet obéit strictement aux règles qui s’appliquent aux variables dans tout langage (type, taille, règles d’affectation…).
On dira également que plusieurs objets qui possèdent les mêmes propriétés sont du même type, ou classe.
La syntaxe qui permet de désigner une propriété d’un objet est « objet.propriété ».
Exemple 1 : le nom d’une boite de dialogue est « index » MSGBOX.name = Index
Exemple 2 : toto = 100
Exemple 3 : toto = toto + 100
Pour ce qui concerne la syntaxe, l’usage des propriétés des objets ne se différencie en rien de celui des variables classiques.
Les langages objet intègre une autre manière d’agir sur les objets : les méthodes.
Une méthode est une action sur l’une – ou plusieurs - des propriétés d’un objet.
Une méthode va supposer l’emploi d’un certain nombre d’arguments, tout comme une fonction. On trouvera donc des méthodes à un argument, des méthodes à deux arguments (plus rares), et aussi des méthodes sans arguments.
Il faut bien faire attention à une chose lorsqu’on utilise des objets.
-
Certains objets sont fournis par le langage de programmation lui-même. Il s’agit en particulier (mais pas seulement) de ce qu’on appelle des contrôles, c’est-à-dire d’objets possédant pour la plupart une existence graphique ; ce sont des éléments de l’interface Windows. Pour tous ces objets que le programmeur utilise alors qu’ils ont été créés par d’autres, les propriétés et les méthodes ne s’inventent pas : chaque type (chaque classe) d’objet possède ses propres méthodes et arguments, qu’il s’agit donc de connaître pour utiliser l’objet en question. Quitte à insister, je répète : connaître, et non inventer.
-
d’autre part, un langage objet ouvre la possibilité de créer soi-même ses propres objets, et donc de programmer leurs propriétés et leurs méthodes. On se situe alors à tout autre niveau, celui de la programmation objet proprement dite. l’essentiel de nos efforts va consister à comprendre comment on peut se servir des objets (en particulier des contrôles) écrits par d’autres
Procédures événementielles
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, 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.
Dans un langage objet, on peut, si on le désire, conserver intégralement ce mode de fonctionnement. mais, 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, 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".
la procédure suivante :
Private Sub Go_Click()
…
End Sub
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.
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.
Compilation et Interprétation
Lorsqu’on écrit une application Visual Basic on crée donc un ensemble d’objets à partir des classes proposées, et on définit les procédures qui se rapportent à ces objets. Lorsqu’on sauvegarde cette application, Visual Basic va créer un certain nombre de fichiers. Pour l’essentiel :
Un fichier dit Projet comportant l’extension *.vbp Ce fichier rassemble les informations générales de votre application (en gros, la structure des différents objets Form, qui sont le squelette de toute application) un fichier par objet Form créé, fichier portant l’extension *.frm.. Toujours est-il que si votre application comporte six Form, vous aurez en plus du fichier "projet", six fichiers "Form" à sauvegarder. Chacun de ces fichiers comporte les objets contenus par la "Form", ainsi que tout le code des procédures liées à ces objets. éventuellement, d'autres fichiers correspondant à d'autres éléments de l'application, éléments dont nous parlerons plus tard (modules, modules de classe.
Conclusion, on crée un nouveau projet à chaque nouvelle application, et on ne déroge jamais à cette règle d’or. Il ne doit jamais y avoir deux projets ouverts en même temps dans la même fenêtre VB, sous peine de graves représailles de la part du logiciel.
Tant que votre projet est ouvert sous cette forme d’une collection de fichiers vbp et frm, vous pouvez naturellement l’exécuter afin de le tester. Lors de l’exécution, le langage est alors ce qu’on appelle « compilé à la volée ». C’est-à-dire que VB traduit vos lignes de code au fur et à mesure en langage machine, puis les exécute. Cela ralentit naturellement considérablement l’exécution, même si sur de petites applications, c’est imperceptible. Mais dès que ça commence à grossir…
Voilà pourquoi, une fois l’application (le "projet") mis au point définitivement, VB vous propose de le compiler une bonne fois pour toutes, créant ainsi un unique fichier *.exe. Ce fichier contient cette fois à lui seul l’ensemble de votre projet, form, code, et tutti quanti. Un projet terminé est donc un projet compilé.
L’interface VB
Le langage possède un vérificateur de syntaxe en temps réel. C'est-à-dire que l’éditeur de code détecte les instructions non légitimes au fur et à mesure que vous les entrez, et il les signale par un texte mis en rouge, et pour faire bonne mesure, par un message d’erreur. Il est donc impossible de laisser traîner des erreurs de syntaxe en VB, VB ne corrige ni les fautes de logique, ni les fautes fonctionnelles. De même, le code est immédiatement mis en couleurs par l’éditeur. le bleu correspond aux mots réservés du langage (instructions, mots-clés...) le vert correspond à un commentaire (toute ligne commençant par un guillemet simple – quote – est considérée comme un commentaire). tout mot reconnu par l'éditeur (nom d'objet, instruction) voit sa première lettre transformée automatiquement en majuscule. tout nom d’objet suivi d’un point voit s’afficher une liste déroulante contenant l’intégralité des propriétés et des méthodes disponibles pour cet objet. A contrario, cela signifie qu’un objet ne faisant pas apparaître une liste déroulante dans le code est un objet non reconnu (qui n’existe pas). De même, une instruction ne prenant pas automatiquement de majuscule initiale est une instruction non reconnue. il est possible de réaliser une exécution pas à pas via la commande appropriée du menu. il est possible d’insérer des points d’arrêt pour faciliter le débogage. dans le cas d’un pas à pas comme d’un point d’arrêt, il est possible de connaître la valeur actuelle d’une variable en pointant (sans cliquer !) la souris sur une occurrence de cette variable dans le code.
Fenêtre d'une application VB en exécution Pas à Pas
|
