C#, un langage objet

 

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'appelle un type. Pour créer une nouvelle variable, il fallait préciser le type utilisé pour la fabrication de cette variable, par exemple un entier, et lui donner un nom par lequel on la désignerait ensuite tout au long du programme. Dans de nombreux langages– dont le C# – il est même possible de l'affecter directement à la création, par exemple par la valeur 100. D'où la syntaxe :

int toto = 100;

En ce qui concerne les objets, le principe est exactement le même, hormis qu'on ne les fabrique pas d'après un type, mais d'après une classe. Si nous disposons par exemple d'une classe Chien, nous allons pouvoir créer autant de chiens individuels que nous voulons. Voilà par exemple un nouveau compagnon :

Chien Rantanplan = 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. On remarque aussi la présence d'une paire de parenthèses après le nom de la classe, ce qui nous évoque irrésistiblement un appel de procédure ou de fonction. Dans le jargon du langage objet, cette instruction new s'appelle un constructeur. Et la réalité est bel est bien conforme aux apparences : en créant un nouvel objet d'après une classe, nous appelons en effet une procédure – plus précisément, une méthode –, le constructeur en question. Dans le cadre de ce cours, nous n'entrerons pas davantage dans ces détails, mais rien ne vous empêche de fouiner le Net pour en apprendre davantage.

Notre classe Chien a forcément été créée avec un certain nombre de propriétés et de méthodes. Pour chaque objet instancié selon cette classe, nous pouvons accéder à ces propriétés et à ces méthodes par la syntaxe suivante, universelle :

NomObjet.NomPropriété

Et également :

NomObjet.NomMéthode

2.2 Propriétés

Admettons pour les besoins de la cause que notre classe Chien possède entre autres propriétés :

• Taille (float)
• Poids (integer)
• Couleur (string)
• Vacciné (bool)

Alors, je le rappelle, ces propriétés étant en réalité des variables – les champs d'une structure – les règles de leur utilisation sont très exactement les mêmes que celles des variables. Sachant que le signe d'affectation, en C#, est le signe d'égalité, je peux donc écrire :

Rantanplan.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 :

Rantanplan.Poids = Rantanplan.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 :

Rantanplan.Poids = Rantanplan.Taille;

L'utilisation de propriétés non numériques ne pose pas davantage de problèmes :

Rantanplan.Couleur = "Beige";

Rantanplan.Vacciné = True;

2.3 Méthodes

Faut-il le répéter, les méthodes sont des fonctions ou des procédures qui ont été définies pour tous les objets d'une classe donnée. Utiliser convenablement une méthode suppose donc de respecter la manière dont la procédure ou la fonction a été écrite. En particulier, comme à chaque fois en pareil cas, il va falloir respecter le nombre et le type des paramètres dont la méthode (la procédure, la fonction) 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.

Lorsque la méthode est un appel de procédure, elle représente en elle-même une instruction à part entière. Lorsqu'elle est un appel de fonction, elle renvoie un résultat. Dans tous les cas, il serait parfaitement absurde d'affecter une méthode comme on affecte une propriété. Les appels aux méthodes pourront donc donner lieu à des lignes du genre :

Rantanplan.Aboyer();

...si la méthode Aboyer s'emploie sans arguments,

Rantanplan.Courir(15);

...si la méthode Courir nécessite un argument numérique, celui fixant la vitesse de course,

Rantanplan.DonnerlaPapatte("gauche");

...si la méthode DonnerlaPapatte réclame un argument de type caractère, 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 histoire d'objets cache une autre plaisanterie, à laquelle j'ai déjà brièvement fait allusion. Celle-ci 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. Alors, 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 est remis en question avec les langages objet. Non qu'on ne puisse plus créer des procédures et des fonctions traditionnelles, 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 à certains objets, qui possèdent un signe particulier : ils se voient à l'écran. Un système d'exploitation tel que Windows est 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 aux 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, par exemple, le clic sur un bouton, le double-clic sur un raccourci, etc. Donc, 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.

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.

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 à sa disposition à l'écran, quelles seront les actions qu'il pourra effectuer sur ces objets (c'est-à-dire les événements qu'il pourra déclencher) et de prévoir les tâches que le programme devra accomplir lors de ces événements.

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, plus exactement par le Framework .NET (une couche logicielle qui sert d'intermédiaire entre C# et Windows, qui parle un langage trop abscons pour nous).

En réalité, dans un programme C#, on peut utiliser des tas d'autres objets (classes) et on peut même en fabriquer soi-même. Nous verrons cela... un peu, et plus tard. Pour le moment, on se contentera de la trousse à outils que le Framework .NET met à notre disposition, ce qui suffira déjà à nous procurer de longues heures de bonheur.

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.

Nous verrons très bientôt comment crééer une procédure événementielle en C#. En attendant, si vous avez compris le mécanisme des procédures événementielles, alors vous avez alors pigé 45 % supplémentaires du cours. Donc, avec les 45 % précédents (ceux des classes, des objets, des propriétés et des méthodes), on en est à 90 %. Tout le reste, c'est de la petite bière. Puisque je vous le dis.