CHAPITRE 19 Langages et outils pour la

programmation orientée
objets

Introduction à la programmation orientée objets 153

 einev Télécommunications mjn

19.1 Les langages «orientés objets»,

quelle utilité ?

La programmation orientée objets est un paradigme plus qu'un langage de programma-

tion. La plus grande partie des principes OO peut être implémentée à travers un langage de
programmation conventionnel. Seul le mécanisme d'héritage requiert un support spécifique
du compilateur pour pouvoir être implémenté de façon élégante.

Ainsi, lorsque l’on désire programmer ”OO”, il n’est pas forcément nécessaire de
changer de langage. Il faut changer d’attitude vis-à-vis du problème; c’est en général plus
difficile que simplement changer de langage.

Au risque de paraître hérétique, on pourrait dire que plus le langage utilisé est élémen-
taire, plus le paradigme orienté objets prend de l’importance. Il est probablement plus impor-
tant de penser en termes d’objets en assembleur qu’en Java. Une des raisons est que Java
apporte une béquille bienvenue pour encourager la démarche OO, alors que l’assembleur ne
propose aucune contrainte.

Les langages peut-être les moins favorables à une transition d’une démarche algorith-
mique vers une attitude "orientée objets" sont les langages intermédiaires, comme C++,
Visual Basic, Delphi ou surtout Ada 95. Le problème est que ces langages permettent une
décomposition algorithmique aussi bien que orientée objets, et l’utilisateur ne se sentira de ce
fait pas forcé de penser en termes objets (pourquoi faire un effort quand ce n’est pas indis-
pensable ?). Ceci est surtout vérifié dans les milieux académiques, où les problèmes que l’on
pose à l’étudiant sont essentiellement de nature algorithmique (par tradition et par inertie,
essentiellement) et où les enseignants ne sont pas toujours convaincus des avantages du para-
digme, parceque n’ayant peut-être jamais eu à maîtriser des problèmes au niveau d’un grand
système.

En réalité, la méthode devrait idéalement être enseignée avant le langage, tant il est
vrai que la méthode ne s’applique pas qu’à la seule informatique (d’ailleurs, la méthodologie
"orientée objets" ne vient pas des informaticiens, qui n’ont pris ce train que très tard, 20 ans
après son invention). Il est possible, et souvent profitable, de modéliser des systèmes maté-
riels (oscilloscopes, automobiles, locomotives) avec ces méthodes et d’en tirer profit au
niveau du design des circuits; ainsi, les principes de modélisation devraient être acquis indé-
pendemment de tout langage, et c’est d’ailleurs bien ce que prônent certaines universités
d’avant-garde, avec des résultats d’ailleurs remarquables.

Quoi qu’il en soit, une longue tradition veut que l’on considère le langage avant la
méthode, et nombre de guerres de religions vaines sont là pour témoigner de ce fait. Mais
peut-être est-il plus facile de s’attacher à un langage qu’à un concept ?

154 Introduction à la programmation orientée objets

einev Télécommunications mjn

19.2 Quelques langages

Il ne s’agit pas ici de commenter les caractéristiques OO de tous les langages connus,
mais simplement de jeter un coup d’oeil sur certains langages connus et d’autres moins con-
nus, voire implémentés uniquement à l’état de prototypes pour en citer les principaux mérites
en fonction d’une utilisation OO.

19.2.1 Smalltalk-80

Smalltalk-80 est la référence en matière de programmation orientée objets. Ce n'est

pourtant pas le premier langage du genre, puisque les principes "OO" datent des années 60,
avec Simula-67. Smalltalk est resté limité au PARC (Palo Alto Research Center) de Xerox
jusqu'à un célèbre article de la revue américaine BYTE d'août 1981. Ce n'est que trois ans
plus tôt que la première conférence sur les langages de programmation, applications et systè-
mes orientés objets (OOPSLA, Object Oriented Programming, Systems, Languages and
Applications) avait vu le jour.

Smalltalk est un langage qui se confond avec un système d'exploitation. Les classes
définies par le programmeur font partie intégrante du système d'exploitation. Par corollaire,
modifier une classe existante revient à modifier le système d'exploitation lui-même. Ainsi, la
classe integer n'est qu'une classe comme toutes les autres en Smalltalk, et de fait est modifia-
ble par l'utilisateur.

Smalltalk est un langage intéressant par son caractère radical. En C++, il est possible
d'utiliser le langage sans pour autant maîtriser le paradigme sous-jacent. C++ est avant tout
une variante ameliorée de C, qui offre des possibilités de programmation orientée objets.
Smalltalk est un langage entièrement conçu autour du paradigme orienté objets, et n'est de ce
fait pas utilisable sans la maîtrise du paradigme. En ce sens, on peut dire que Smalltalk est le
meilleur langage pour qui veut apprendre à maîtriser ce paradigme.

Smalltalk a les inconvénients de ses avantages. Il est difficile à interfacer avec d'autres
langages, car il implémente aussi en grande partie le système d'exploitation. En fait, l'envi-
ronnement d'exécution de Smalltalk ressemble un peu au vieux P-system rencontré aux
débuts de la micro-informatique pour certains dialectes de PASCAL. Il est difficile d'implé-
menter d'autres langages sur ce genre de systèmes, non pour des raisons techniques, mais sur-
tout pour des raisons de marketing.

19.2.2 Objective-C

Objective C aurait pu avoir la place qu'a prise C++ aujourd'hui. Le créateur de Objec-
tive C, Cox, est l'un des principaux promoteurs du paradigme orienté objets. Objective C
tend à introduire la notion de circuit integré logiciel (Soft-IC). NextStep, l'un des environne-
ments de développement les plus sophistiqués qui soient, a entièrement été développé à l'aide
de Objective C. Alors que C++ se concentre sur la performance du langage (puissance, com-
plexité), Objective-C tend à mettre l'accent plutôt sur la réutilisabilité du code.

Introduction à la programmation orientée objets 155

 einev Télécommunications mjn

Il paraît actuellement plus que probable que Objective C est voué à une disparition pro-
gressive. Hélas, serait-on tenté de dire, car le langage possède certaines particularités intéres-
santes, comparé à C++.

19.2.3 Ada-95

ADA n'était pas un langage orienté objets, l’introduction en 1995 d’une nouvelle ver-
sion du langage a corrigé ce manque. ADA est un langage très complet, d’une philosophie
radicalement opposée à C++. Là où C et C++ comptent sur l’introduction de librairies pour
étendre les fonctionnalités du langage (concurrence, par exemple), ADA inclut ces possibili-
tés dans le langage même. C n’a fait l’objet d’une spécification que plusieurs années après sa
naissance, alors que ADA est un des langages les mieux spécifiés qui soit. Malgré ses quali-
tés, ADA n’a pas su s’implanter valablement dans bon nombre de domaines; typiquement, le
monde des télécommunications, pourtant l’un des principaux clients de l’informatique, n’a
pas emprunté le train ADA.

C’est surtout dans le domaine des processus industriels qu’ADA a pu s’imposer en par-
tie; il faut toutefois garder à l’esprit qu’ADA est un langage mis sur pied par le DOD
(Department Of Defense); son utilisation première est de ce fait orientée vers le temps réel et
les processus concurrents étroitement liés (pour lesquels il est possible, par exemple de défi-
nir un rendez-vous). Cette conception se répercute sur les utilisations de ce langage.

19.2.4 Object Pascal

Sous ce vocable sont regroupées toutes les tentatives de divers implémentateurs pour
définir un dialecte de PASCAL (un de plus!) qui supporterait les constructions orientées
objets. La plupart de ces constructions ont en commun leur implémentation de la classe en
PASCAL, par le truchement de la construction RECORD...END.

Parmi les constructions méritant le droit de cité, nous mentionnerons LISA PASCAL
de Apple, avec lequel fut écrit le système d'exploitation de LISA (l'ancêtre malheureux du
Macintosh), puis du Macintosh, et le Pascal de Borland, qui à partir de la version 6, suppor-
tait les constructions OO selon le modèle RECORD...END.

19.2.5 Pascal-XT

Sous cette appellation se cache l'une des implémentations de PASCAL les plus riche et
étendue qui ait jamais été réalisée. Pascal-XT reprend les notions de Modules de MODULA-
2, ajoute les exceptions de Ada, implémente les fichiers ISAM (Indexed Sequential Access
Mode de COBOL) dans le langages, etc... Il ne s'agit pour autant pas d'un langage OO, mais
d'un langage possédant beaucoup des propriétés de C++.

19.2.6 CLOS

Common Lisp Object System. Extension orientée objets de Common Lisp devant faire
l'objet d'une standardisation, résultant de la mise en commun des expériences avec d'autres

156 Introduction à la programmation orientée objets

einev Télécommunications mjn

dialectes OO de Lisp. Langage interprété, sans bibliothèque standard, mais très bien intégré.
Supporte l'héritage simple et multiple, est (selon l'usage dans le cadre de Lisp) faiblement
typé, et procure un large soutien aux métadata (données décrivant les données, procure une
indirection supplémentaire). Une de ses particularités est la possibilité de définir des nouvel-
les méthodes, de générer de nouvelles classes en cours d'exécution.

19.2.7 Eiffel

Eiffel est un préprocesseur qui génère du langage C. En ce sens, il a les mêmes origines
que C++; mais il va infiniment plus loin dans son implémentation du concept "orienté objets"
que ne le fait C++. Alors que C++ ne fait que mettre à disposition des outils qui permettent
de programmer de manière orientée objets pour le programmeur qui veut bien s'en donner la
peine, Eiffel impose, un peu à la manière de Smalltalk, l'utilisation du paradigme.

Eiffel est considéré comme une des meilleures implémentations de langage OO par
beaucoup d'auteurs spécialisés. Il n'a néanmoins que peu de chances de sortir d'un contexte
d'applications relativement marginal, du fait du succès de C++ et de Java, et de l'établisse-
ment de ces langages comme standard de facto.

L'un des principaux inconvénients d'Eiffel actuellement tient à son implémentation en

tant que préprocesseur: il n'existe pas de débogueurs performants pour ce langage.

19.2.8 Sather

Sather est un langage dérivé de Eiffel, dans le sens d'une simplification, et d'un accrois-
sement d'efficacité. Sather est un langage très récent, dont quelques critiques disent que c'est
ce que l'on fait de mieux pour l'instant (Eiffel sans ses défauts ???).

19.2.9 Modula-3

Modula-2 possédait pas mal de propriétés des langages OO, comme la possibilité
d'encapsuler les données, et un mécanisme d'initialisation des données privées très propre.
Modula-3 est une extension OO de Modula-2 qui fut introduite par Digital Equipment Cor-
poration, et diffusée comme freeware. Modula-3 n'a jamais connu de succès notable, mais
reste intéressant par beaucoup de caractéristiques. Sans imposer le paradigme OO, Modula-3
encourage suffisamment son utilisation pour qu'elle devienne naturelle.

Par ailleurs, la syntaxe de MODULA est infiniment plus élégante que la syntaxe C++,
avec ses opérateurs dont le sens dépend du contexte. Par contre MODULA a le défaut des
langages de cette famille : les entrées-sorties sont inadéquates, pour ne pas dire catastrophi-
ques.

Par ailleurs, Modula 3 souffre des mêmes défauts que Modula 2, en dépit des efforts
des concepteurs de DEC: trop théorique, il se prête mal à une utilisation industrielle, et est
d'autre part victime de l'énorme effet d'inertie crée par les bibliothèques C existantes, relati-
vement à l'absence totale de librairies normalisées dans la famille MODULA. On peut dire
sans risques de trop se tromper que Modula-2/3 aurait pu concurrencer C/C++ avec de très

Introduction à la programmation orientée objets 157

 einev Télécommunications mjn

bonnes chances de réussites, s'il avait été doté au départ d'une librairie spécifiée avec une
ampleur comparable à celle que C propose, ainsi que d'un souci de compatibilité dans sa con-
ception avec les mécanismes d'appels typiques à C.

19.2.10 Java

Développé par Sun Microsystems, Java est un dialecte de C++ (un sous-ensemble, en
fait) conçu pour être interprété indépendemment de la plate-forme matérielle. Le but princi-
pal de Java est de servir d’outil de programmation au monde du World Wide Web, en éten-
dant ainsi les possibilités de HTML par le concept de applet, sorte de mini-applications
téléchargeables depuis un serveur distant.

Ce but originel a depuis été nettement dépassé, et Java est devenu un langage à usage
universel. Les nouvelles machines virtuelles et des techniques de compilation "Just In Time"
ont réduit l’inconvénient de lenteur de Java jusqu’à concurrencer C++ dans la plupart des
applications, voire à le dépasser dans certains cas bien particuliers. Son indépendance relati-
vement à la plate-forme matérielle et l’avénement de Linux sur le marché ont conduit nom-
bre d’acteurs majeurs de la scène informatique (IBM, Oracle, Alcatel, Inprise, Iona, en fait
tous sauf Microsoft) à faire de Java l’une de leurs priorités majeures.

Java est une des plus intéressantes nouveautés de ces dernières années. Il s’agit d’un
langage très sûr (parceque pouvant être téléchargé au travers d’Internet), optimisé (pour les
mêmes raisons), et suffisamment simple pour pouvoir être aisément maîtrisé. Un program-
meur habitué à C++ apprend Java en quelques heures. Java renonce aux caractéristiques les
plus puissantes (mais aussi les plus dangereuses) de C++ pour simplifier et “sécuriser” le lan-
gage :
• Pas de pointeurs (et par conséquent, pas d’arithmétique de pointeurs)
• Pas d’héritage multiple (complexe, et relativement peu utilisé)
• Pas de surcharge d’opérateurs
• Gestion “automatique” de la mémoire (garbage collector)

Java est souvent présenté comme une sorte de panacée, car il est indépendant du sys-
tème d’exploitation : une “applet” Java peut s’exécuter en principe aussi bien sur une
machine UNIX (avec MOTIF ou OpenLook comme système de fenêtrage) que sur Windows
NT ou un Macintosh.

Noter encore l’incroyable richesse des bibliothèques de Java, et son orientation forte-
ment "distribution". Il n’existe pratiquement pas de problèmes pour lesquels un élément de
solution n’a pas déjà été écrit en Java. Des outils très novateurs (Cocoon, JetSpeed, Turbine,
Fire, etc...) sont disponibles de manière gratuite sur Internet.

19.2.11 Borland Delphi et Visual Basic

Ces deux environnements de développement ne sont pas à proprement parler orientés

objets, bien qu’ils comportent des caractéristiques des langages OO (en particulier l’encapsu-
lation des données). Ils sont néanmoins dignes d’être cités dans ce cadre, car ils encouragent

158 Introduction à la programmation orientée objets

einev Télécommunications mjn

l’utilisation de la philosophie OO dans l’optique de la programmation d’interfaces utilisa-

teurs.

Du point de vue de l’auteur, les deux environnements possèdent des caractéristiques et

des possibilités similaires, mais Delphi est beaucoup plus propre (PASCAL vis-à-vis de
Basic, ou l’ETHZ face à Microsoft ...) et peut de surcroît s’interfacer facilement à C++ (le
compilateur de Borland uniquement, bien évidemment) dans la version 32 bits.

19.2.12 C++

Faut-il appeler C++ un standard de la programmation OO? Pourtant, C++ n'est pas un
langage OO. C'est un langage procédural tout à fait classique qui a été étendu pour supporter
des constructions OO. C++ reste fidèle aux principes qui furent à la base de C: le program-
meur est un être pleinement responsable de ce qu'il fait, et il est hors de question de lui impo-
ser des limites, quelles qu'elles soient. Ainsi, si le programmeur veut programmer en C++,
mais ne veut pas avoir à se préoccuper de paradigmes OO ou autres, il peut le faire. C++ sera
pour lui un C amelioré (a better C, comme le dit Bjarne Stroustrup, concepteur du langage).
Beaucoup d'industries, lorsqu'elles se voient obligées de changer d'environnement de déve-
loppement, considérent ce fait comme un avantage, comptant sur le fait qu'elles auront moins
à investir dans la formation de leurs collaborateurs. Il s'agit portant d'une réflexion falla-
cieuse, car les collaborateurs tendront à utiliser C++ comme C, et progressivement se met-
tront à utiliser les nouvelles possibilités qu'offre ce langage sans en comprendre toute la
portée. Utiliser des mécanismes sans en comprendre la portée est dangereux dans n'importe
quel langage; en C ou en C++, n'hésitons pas à dire que c'est suicidaire.

Si par contre, il désire utiliser le langage avec toutes ses potentialités, C++ met à la dis-
position du programmeur des outils aussi puissants (et aussi potentiellement dangereux) que
l'héritage (simple et multiple), la surcharge de fonctions et d'opérateurs, le traitement
d'exceptions et les modèles (templates). Mais le programmeur est alors laissé en partie à lui-
même pour ce qui concerne l'utilisation de ces outils.

C++ est actuellement le langage OO dont on parle le plus, et que l'on utilise le plus. Ce
n'est certainement pas le meilleur langage OO (pour autant que ce soit un langage OO, cf. çi-
dessus), mais il a la force que confère un nombre elevé d'utilisateurs. Le nombre d'utilisa-
teurs élevé encourage les fournisseurs d'infrastructure à implémenter des interfaces de pro-
grammation (API, Application Programming Interface) en C++, ce qui tend à nouveau à
augmenter le nombre d'utilisateurs, etc...

C++ a énormément bénéficié de ses origines, proches de UNIX et de la conception de

C (Bjarne Stroustrup, concepteur de C++, vient de AT&T, division USL, Unix Systems
Laboratories). Des préprocesseurs pour UNIX furent très tôt disponibles, et le support incon-
ditionnel de C avec un interfaçage sans problèmes ont été des facteurs déterminants dans
l'acceptance actuelle de C++ en tant que "standard OO".

C++, tel qu'il se présente actuellement, n'est probablement pas ce qu'un informaticien
appellerait un bon langage, pas plus que C. Mais il existe, et il est utilisé par un nombre de
programmeurs considérable. Les mondes UNIX et Windows NT, entre autres, en ont d'ores et
déjà fait un quasi standard. Ceci suffit amplement pour que ce langage soit important. Hor-

Introduction à la programmation orientée objets 159

 einev Télécommunications mjn

mis ces considérations, C++ possède également les qualités de C, à savoir des possibilités de
programmation à des niveaux très divers, permet d'éviter plusieurs des pires défauts de C, et
peut s'appuyer sur une bibliothèque existante considérable, surpassée uniquement par les
bibliothèques FORTRAN et Java. Ces derniers points sont déterminants pour son utilisation
dans un cadre industriel.

Malgré la concurrence actuelle faite par Java, C++ reste actuellement encore le langage
le plus utilisé pour les applications orientées objets.

19.2.13 Divers

La plupart des langages conventionnels ont développé des extensions objets, comme
COBOL, FORTRAN, CHILL; ces extensions ne vont probablement pas sauver ces langages
relativement vétustes des utilisations auxquelles ils se trouvent confinés actuellement. De
plus, il existe nombre de langages un peu expérimentaux (Newton, Dylan et beaucoup
d’autres) sans aucune prétention industrielle que nous ne citerons pas plus avant dans ce
cadre malgré leur indiscutable intérêt théorique.

160 Introduction à la programmation orientée objets

einev Télécommunications mjn

19.3 Outils de modélisation

Les outils de modélisation sont un auxiliaire indispensable pour la conduite de projets

de grande envergure, que l’on se trouve dans un environnement objet ou non. Il se trouve
qu’il est généralement plus facile de modéliser formellement un système selon le paradigme
“orienté objets” que selon les méthodes traditionnelles.

19.3.1 Rational Rose (www.rational.com)

Rational Rose est la référence incontournable, puisque c’est la société Rational qui a
défini en grande partie le langage UML. Cette société compte d’ailleurs parmi ses fondateurs
et principaux responsables des personnalités comme Booch, Rumbaugh et Jacobsen. Ratio-
nal Rose permet la génération de code à partir du modèle, pour des langages comme C++,
Ada, Visual Basic ou Java, par exemple.

Rational Rose est un produit bien adapté à une entreprise, mais extrêmement lourd
pour une PME ou une école. Rose réclame une administration de produit, ce qui n’est pas à la
portée de toutes les entreprises, et surtout un apprentissage considérable pour tirer du produit
les bénéfices qu’il est susceptible d’apporter.

La puissance de Rational Rose est à relativiser dans beaucoup de cas. Pour qui a les
moyens de se payer Rational Rose et surtout de l’entretenir valablement, et de l’accompagner
d’un outil de gestion de produit du genre Clear Case ou autre, le prix de la licence se justifie
probablement, car le genre de projets que gère cette entreprise est vraisemblablement à la
hauteur de l’outil qu’elle a acquis et des investissements en apprentissages qu’elle entend lui
consacrer. Celui qui choisirait Rational Rose simplement parcequ’il implémente tel ou tel
langage de projection que n’implémente pas un concurrent plus modeste ferait une erreur qui
certes ne toucherait que son porte-monnaie. On ne choisit pas un outil de modélisation à
cause d’un langage : on choisit une méthode de modélisation, et ensuite on se pose la ques-
tion du langage que l’on choisira. Il est vrai que souvent, le langage est une philosophie
d’entreprise, et difficile à changer. On pense donc que l’on va gagner du temps en conservant
le même langage... Il est certain qu’il s’agit d’une erreur de jugement fondamentale : un pro-
grammeur, même peu habile, n’a jamais eu trop de difficultés à changer de langage. Par con-
tre, changer de paradigme peut s’avérer très compliqué pour certains, surtout si l’on conserve
le langage dans lequel on a pris ses habitudes et ses aises !

19.3.2 Together (www.togethersoft.com)

Nous avons décrit Together au cours de cet exposé, en présentant un outil de modélisa-
tion comme exemple. Nous ne reviendrons pas sur le produit dont les qualités sont évidentes.
Signalons toutefois que relativement à Rose, il est écrit en Java et tourne donc sur la majorité
des plate-formes, et autorise moins de langages de projection. En revanche, son prix et sa
qualité encouragent fortement son utilisation par des PME et des écoles. Il ne requiert en
principe aucune maintenance particulière.

Introduction à la programmation orientée objets 161

 einev Télécommunications mjn

19.4 Pourquoi si tard ?

Si la programmation orientée objets est si bénéfique, pourquoi ne l'introduit-on que

maintenant ? On a vu que les principes datent de plus de 30 ans (Simula-67), donc il semble
que l'on aurait pu introduire ces principes beaucoup plus tôt.

La question est justifiée, et ne comporte pas de réponse univoque. Simula-67 est de

tous temps resté un langage très confidentiel, à une époque où FORTRAN et COBOL se dis-
putaient les temps de calcul des brontosaures d'Informatic Park (trad. mainframes). Les pro-
blèmes que l'on adressait alors ne nécessitaient guère l'utilisation de techniques sophistiquées
de programmation, car ils étaient généralement de nature mathématique ou comptable. En
d’autres termes, le problème à résoudre ne concernait pas l’informatique, mais les mathéma-
tiques et la comptabilité.

L'essor de l'informatique dans le cadre des télécommunications eût pu provoquer cette

révolution beaucoup plus tôt, mais elle ne l'a pas fait, parcequ'à l'époque où elle eût pu le
faire, la mode était plutôt aux langages structurés comme PASCAL et CHILL. Ada est proba-
blement le dernier avatar des langages dits "procéduraux". Comme tant d’autres (Object
Chill, Object Fortran, Object Cobol), il a essayé de s’adapter au paradigme objets, mais pas
assez tôt (C++), ni assez radicalement (Java).

CHILL est d'ailleurs un langage défini par les instances de normalisation internationa-
les en matière de télécommunications, ITU (International Telecommunication Union, ancien-
nement CCITT, Conférence Consultative Internationale pour la Téléphonie et les
Télécommunications). Une fois cette normalisation décidée, l'inertie des grands systèmes a
joué à plein: il était trop tard pour faire marche arrière. De fait, il semble hors de question
que les logiciels des centraux publics soient un jour traduits en un langage OO; tout au plus
développera-t-on éventuellement la prochaine génération en un tel langage.

Il a fallu attendre XEROX et Smalltalk pour que l'on commence à parler de "orienté
objets" dans un cercle un peu moins confidentiel que ceux des initiés. Et encore n'y vit-on à
l'origine qu'un interface utilisateur (à l'instar de Steve Jobs, qui en pirata le Macintosh,
XEROX pas plus que Steve Jobs n'ayant pas compris le potentiel commercial caché derrière
le système). Il fallut encore pas mal de temps pour comprendre ce qu'il y avait derrière la
façade de Smalltalk, puis il fallut implémenter ces principes dans des langages utilisables à
l'échelle industrielle. Ceci explique en partie l'ignorance du paradigme "OO" jusqu'à la fin
des années 80.

162 Introduction à la programmation orientée objets

einev Télécommunications mjn

19.5 Universellement applicable ?

Il y a quelques années, on hésitait à appliquer le paradigme orienté objets à certains

domaines, réputés "temples de la religion procédurale". Actuellement, pratiquement tous les
"interdits religieux" ont sauté, et il n’y a plus guère que dans le domaine des systèmes à
microcontrôleurs ou à processeur de signal que l’on hésite à faire le pas.

En dépit des doutes de certains, il semble indiscutable que le modéle objets colle plus à
la réalité que le modèle procédural; n’en déplaise à ceux qui trouvent le modèle objets trop
abstrait, mais nombre d’écoles, et non des moindres, ont introduit ce modèle en première
année, et considèrent l’expérience comme très positive.

Universellement applicable ? Oui, sans hésiter. Peut-être les domaines où les ressour-
ces sont coûteuses (programmation de bas niveau, capteurs, DSP) sont-ils moins touchés.
Mais actuellement déjà, des systèmes embarqués (téléphones portables) sont devenus suffi-
samment complexes pour qu’une transition vers l’orientation objets s’avère indispensable.

Introduction à la programmation orientée objets 163

 einev Télécommunications mjn

19.6 La panacée ?

La programmation orientée objets est-elle une bonne chose ? Est-ce la panacée, le "Sil-
ver Bullet", la balle en argent de Cox qui doit permettre de conjurer le mauvais sort qui
s'acharne sur le développement de logiciel ? La réponse est difficile à formuler, et peut-être
n’existe-t-elle pas. En août 1981, la revue Byte faisait de la programmation orientée objets sa
page de couverture. En mai 1994, la page de couverture de ce même Byte mentionne en
caractères gras "Object oriented computing has failed"... L'article faisant l'objet de la couver-
ture attaque en particulier l'utilisation du paradigme OO pour développer du logiciel réutili-
sable. Dans ce contexte, il essaie de démontrer que la notion de classes réutilisables basées
sur le polymorphisme, l'héritage simple et multiple ne sont pas utilisables sans autres par de
tierces personnes. On y compare les classes réutilisables aux outils personnalisés définis par
des systèmes comme Visual Basic, dont le succès considérable a surpris les responsables de
Microsoft eux-même. Ces outils sont, dans cet article signé John Udell, appelés "orientés
composants" plutôt que "orientés objets".

Les outils de Visual Basic, au lieu de se fonder sur le polymorphisme et l'héritage mul-
tiple, se contentent de la simple encapsulation des données. Mais la comparaison est biaisée
par le fait que la base de comparaison consiste en des éléments d'interface, de dialogue uni-
quement. Visual Basic est un produit dédié au développement rapide de surfaces utilisateurs
par des non-informaticiens, et remplit parfaitement son rôle dans ce créneau particulier dédié
aux ingénieurs de régulation, d’instrumentation, de techniques de mesure, agronomes, etc..
Les éléments de dialogue ayant été définis une fois peuvent être réutilisés; ceci n'est pas le
fait du langage ou d'un paradigme de programmation quelconque: c'est l'environnement de
travail qui met à disposition ces possibilités. On peut parfaitement imaginer un outil permet-
tant de faire la même chose en C++.

Les ingénieurs manipulant des problèmes plus ambitieux se verront vite limités par ce
type d’outils, qui n’offrent souvent pas assez de flexibilité: il est en effet difficile d’être sim-
ple et flexible à la fois.

Java a très tôt introduit la notion de composant avec ses Java Beans, particulièrment
faciles à utiliser. CORBA propose des composants indépendents du langage. Il est vrai
qu’étant le langage défini en dernier, Java pouvait se permettre de corriger les défauts de tous
les langages précédents.

164 Introduction à la programmation orientée objets

einev Télécommunications mjn

19.7 En guise de conclusion provisoire

Ces aspects négatifs ne doivent pourtant pas faire perdre de vue les avantages fonda-
mentaux de la technique de programmation orientée objet. Pas plus que la programmation
structurée, la programmation orientée objets n'est sans doute la solution miraculeuse que l'on
pensait avoir découverte. Mais il est certain que la programmation orientée objets est un
sérieux pas en avant par rapport à la programmation structurée, au moins comparable au pro-
grès qu'avait en son temps représenté la programmation structurée elle-même. En dépit de
l'article négatif de John Udell dans Byte de mai 1994, la programmation orientée objets
représente un moyen efficace de réutiliser du code, et ceci non seulement dans le domaine
des surfaces utilisateur. D'autre part, son paradigme "orienté composants" plutôt que "orienté
objets" n'est qu'un sous-ensemble du paradigme plus général OO. Une bibliothèque "orientée
composants" peut être implémentée en n'importe quel langage supportant l'encapsulation,
donc également en C++ ou en Java. Il est en revanche douteux que des composants avec des
comportements plutôt globaux puissent être utilisés dans un contexte plus général que les
surfaces utilisateurs et les bases de données. Il est vrai que ces deux composantes représen-
tent une proportion non négligeable du code produit. (près de 70%, selon diverses sources).

Le futur de l'informatique utilisera presque certainement -et l’utilise déjà- la program-

mation orientée objets dans une large mesure. Mais il est vraisemblable que d'autres méca-
nismes viendront compléter, plutôt que remplacer, les mécanismes de base de la
programmation OO. Parmi ces mécanismes, citons, dans le désordre, Distributed Common
Object Model (DCOM) de Microsoft, Distributed System Object Model (DSOM) d'IBM,
Distributed Objects Everywhere (DOE) de Sun, Distributed Object Management Facility
(DOMF) de HP, Portable Distributed Objects (PDO) de Next, JavaBeans de Sun Microsys-
tems, et finalement Common Object Request Broker Architecture (CORBA) de l'Object
Management Group (OMG). Le dernier cité est une composante standard de l'OSF (Open
Systems Foundation). Tous ces mécanismes tentent de compléter la programmation orientée
objets, pour permettre une meilleure réutilisabilité du code au travers de machines et de com-
pilateurs divers. Mais pour maîtriser ces mécanismes, il faut d'abord maîtriser le paradigme
OO.

Introduction à la programmation orientée objets 165

 einev Télécommunications mjn

166 Introduction à la programmation orientée objets