Mise en œuvre
Langages à objets

Dix ans après son apparition en force, la technologie à objets se porte bien. Son succès s’affirme dans presque tous les domaines de l’informatique. Plusieurs congrès internationaux lui sont consacrés chaque année en Europe, aux États-Unis et dans le Pacifique, les revues se multiplient ainsi que les réunions plus ou moins tapageuses à caractère commercial. On y entend souvent parler des technologies à objets, au pluriel. C’est que ce succès s’accompagne d’une confusion notable, les spécialistes des différents domaines ne donnant pas le même sens technique au mot objet, mot magique déjà lourdement chargé de sens dans la langue courante. Le barbarisme orienté objets, traduction directe de l’anglais object-oriented, n’aide pas à clarifier les choses. Nous lui substituons une terminologie plus conforme à la grammaire française : programmation par objets, langages à objets.

Pour éviter les malentendus, il convient de distinguer les domaines. Comme toute technique de programmation, la programmation par objets proprement dite peut se pratiquer en principe dans n’importe quel langage, mais de préférence à travers les langages à objets. Elle s’utilise à peu près partout, mais avec un éclat particulier lorsqu’il s’agit d’écrire des systèmes complexes. Elle rencontre alors les préoccupations du génie logiciel et donne naissance à l’analyse et conception par objets qui, à travers les multiples méthodes proposées sur le marché (comme OOA, OODLA, HOOD, OMT, etc.), pose des problèmes profonds d’acquisition des connaissances et rejoint une branche de l’intelligence artificielle en développement rapide. Comme le point de vue des objets est aux antipodes du modèle relationnel, les bases de données à objets ont fait leur apparition sur le marché . Les systèmes d’exploitation à objets vont entrer en service d’un jour à l’autre, et on va voir se multiplier les applications distribuées fondées sur des objets concurrents. Les objets qui ont cours dans ces derniers domaines doivent affronter des conditions de vie difficiles (persistance, distribution), et ils ne sont plus exactement ceux des langages à objets classiques (cf. le standard CORBA promu par l’organisation OMG). Du côté de l’intelligence artificielle, la représentation de connaissances utilise elle aussi des objets, qui sont en fait dérivés des frames et se différencient de ceux qui nous occupent ici dans leur intention (par exemple la classification) comme dans leur structure (absence de la composante procédurale).

Nous nous limitons dans le présent article aux langages (de programmation) à objets dans la perspective de leur utilisation en production de logiciel (et non, par exemple, du point de vue de l’intelligence artificielle). Nous n’aborderons pas l’analyse et la conception par objets, qui demanderaient un développement à part dont celui-ci est un préliminaire indispensable. De même, nous n’examinerons pas les problèmes liés à la permanence, à la concurrence et à la distribution des objets, ni les perspectives de systèmes d’exploitation ou de bases de données.

Notre présentation sera guidée par le principe d’implémentation qui sous‐tend la programmation par objets, plutôt que par une analyse a priori des besoins qu’elle devrait satisfaire et des moyens qu’elle propose. C’est à notre avis la seule façon d’évaluer sainement les possibilités de la technique, les constantes et les variations entre les différentes réalisations, et surtout, pour l’utilisateur, de ne pas prendre ses désirs pour des réalités. Cette dernière tentation est particulièrement forte en programmation par objets, en raison d’une ambiguïté fondamentale que nous analyserons longuement. En fin de compte, c’est sans doute cette ambiguïté qui est la source de la fécondité et de la richesse de la programmation par objets, mais il faut en être bien conscient pour ne pas se faire prendre aux pièges du vocabulaire et pour ne pas se laisser désorienter par les débats interminables sur le sens des mots qui surgissent dès que l’on pose la question : « qu’est-ce qu’un objet ? ».

Si l’on se borne aux logiciels qui sont effectivement utilisés de manière industrielle, par opposition aux systèmes à caractère expérimental ou d’usage restreint, la diversité apparente des langages à objets actuellement disponibles se ramène à une architecture unique, le schéma dit à classes et instances, expression où le mot classe doit être pris en un sens technique précis 2.2. Ce schéma repose en vérité sur une technique d’implémentation d’une remarquable simplicité, qui a des conséquences multiples et lointaines. Nous l’analyserons en trois temps. D’abord, la structure profonde du modèle à classes et instances, suivant ses deux aspects indissolublement liés de mécanisme intellectuel et de réalisation informatique : l’un ne va pas sans l’autre. Ensuite, nous passerons en revue, à la lumière de ces principes, les langages les plus connus. Enfin, nous ferons une analyse critique en confrontant les moyens de programmation ainsi définis avec les desiderata des utilisateurs, qui leur sont souvent fort étrangers.