|
|
|
|
|
 |
Un
bilan critique de la programmation orientée
objet
par Alain
Lefebvre
Directeur
de la stratégie technique, eFORCE
France
|
|
| |
 |
| |
Les composants logiciels représentent
un vieux rêve de tout informaticien (surtout des
développeurs): assembler des briques plus ou moins
élémentaires plutôt que d'écrire
toujours les mêmes lignes de code, quel gain de
temps et de qualité !
L'industrie informatique s'est enflammée à
cette idée aussitôt baptisée "programmation
orientée objet (ou POO)". Aujourd'hui, après
bien des années d'une progression lente, il est
communément admis que la POO s'est largement et
définitivement imposée. Toutefois, cet achèvement
ressemble bien à un triomphe par défaut
car qu'en est-il des bénéfices que l'on
attendait de cette avancée ?
En
matière de POO, c'est le règne de la pensée
unique : personne ne conteste son intérêt,
personne ne conteste son triomphe et personne ne remet
en cause ses résultats. Je ne suis pas de cet avis
depuis des années et, aujourd'hui, il est peut-être
temps de faire un bilan objectif de ce que nous a apporté
ce "progrès"...
Revenons
tout d'abord sur les avantages que nous promettait initialement
l'utilisation de la POO :
- développer plus vite les applications grâce
à la réutilisation;
- maintenance facilitée grâce à un
code plus propre;
- une plus grande souplesse et adaptabilité des
applications.
On va se contenter de cela, c'est déjà pas
mal !
Mais, face à ces avantages séduisants en
théorie, des obstacles pratiques se sont dressés
sur le terrain :
- la POO demandait (et demande toujours) un niveau de
compétence élevé (il faut comprendre
les concepts de la POO en profondeur afin de les appliquer
correctement et ils n'ont rien à voir avec ceux
de la programmation "classique");
- la POO exigeait (et exige toujours) que le code et les
objets produits soit très largement documentés
afin d'être effectivement réutilisables;
- les performances en exécution des applications
développées en respectant les principes
de la POO ont souvent été décevantes,
nécessitant de pratiquer des "raccourcis"
pas toujours propres ni faciles à mettre en place.
Examinons ne serait-ce que l'aspect maintenance des applications
développées selon les principes de la POO.
Tout d'abord, rappelons-nous que les meilleurs développeurs
ne font PAS de maintenance car, d'une part, on préfère
consacrer ses meilleures ressources aux projets les plus
stratégiques (et la maintenance d'applications
existantes est rarement considérée comme
"stratégique") et, d'autre part, les
stars rechignent à travailler sur autre chose que
du développement "neuf"...
La POO a permit d'éclaircir le code car le C++
a succédé au C, qui n'est pas réputé
pour laisser du code clair. Un programme complexe écrit
en C (ou n'importe quel langage non objet) peut rapidement
devenir une horreur à lire, car il y a des variables
globales partout. Mais on n'a pas gagné en lisibilité
parce que les programmeurs ont pu "aller plus loin"
grâce à l'abstraction apportée par
la POO ce qui a conduit en fin de compte à encore
plus d'opacité. Donc, au lieu d'être facilitée
la maintenance est devenue terrible !
Pareil pour la réutilisation:
il était illusoire d'espérer obtenir de
bons résultats en allant à l'encontre de
la nature humaine et surtout de la façon de travailler
des développeurs. Les développeurs n'aiment
pas réutiliser des objets parce que ces derniers
ne sont pas transparents (on sait ce qu'ils font mais
pas comment ils le font) mais ils n'aiment pas non plus
réutiliser du code (qui lui est transparent !),
pourquoi ? Les développeurs qui proclament volontiers
qu'ils sont paresseux n'aimeraient-ils pas réutiliser,
quelle que soit la forme ?
Eh bien, pour réutiliser, il faut d'abord lire
le code à intégrer afin de le comprendre.
Or, les développeurs n'aiment pas lire le code
des autres, parce que c'est un exercice difficile pour
ne pas dire pénible. Essayez donc de relire votre
propre code des mois après l'avoir écrit…
C'est le syndrome du "not invented here" (je
réécrit mes classes parce qu'au moins comme
ça, je sais comment c'est implémenté
en interne).
Pourtant, on incite
fortement les développeurs à faire un large
usage de la réutilisation et à œuvrer
dans ce sens en transformant leurs codes en composants
qui seront à leur tour repris. D'un autre côté,
on les incite aussi par-dessus tout à respecter
les délais... Bon, voici une belle (et classique)
matrice de contraintes contradictoires !
De deux choses l'une : soit le développeur réutilise
et fabrique de nouveaux composants mais cela lui demande
du temps (chercher et comprendre le fonctionnement des
objets d'une part, documenter et archiver de nouveaux
objets d'autre part) et du coup risque de n'être
plus dans les temps (management mécontent), soit
le développeur tient les délais mais en
faisant fi de toutes tentatives de réutilisation
et le management n'est toujours pas content...
Voilà typiquement une situation à éviter
à tout prix, une situation où le développeur
est toujours perdant ! En fin de compte, les meilleurs
exemples de réutilisation de code objet sont les
libraries fournies avec les compilateurs (MFC de Microsoft
par exemple).
Bref, le potentiel
théorique de la POO était énorme
mais pas nécessairement bien placé par rapport
aux difficultés du terrain. Mais alors, dans ce
cas, pourquoi la POO s'est elle imposée ?
La POO s'est imposée parce qu'elle a d'abord été
utilisée par les vrais pros du coding : les équipes
de développement des éditeurs de logiciels
(pas sans difficultés : il y a eu des "accidents"
célèbres où au lieu de se traduire
en un avantage compétitif, le recours à
la POO a précipité la chûte de tel
ou tel projet et quelquefois de son éditeur !).
Progressivement, cette adoption de la POO par les pros
s'est traduite par un asséchement du marché
: tous les outils de développement adoptaient les
règles et principes de la POO. Alors que l'approche
objet échouait dans le domaine des bases de données
et des systèmes d'exploitation, elle s'est finalement
trouvé une place dans les environnements de développement
où même le Cobol s'est mis à la page.
Le triomphe apparent
de la POO est la face visible d'un phénomène
classique : la fatale attraction de l'état de l'art
! Tout le monde veut " l'état de l'art "
(que ce soit en matière de programmation avec la
POO ou dans d'autres domaines) mais, en réalité,
bien peu sont en mesure d'en tirer parti.
La POO a été
victime de trop de hype (comme toujours) : il n'y
a pas eu les gains phénoménaux espérés
car les résultats dépendaient grandement
du développeur / chef de projet. La POO n'est pas
la méthode-miracle-qui-permet-d'obtenir-des-bons-résultats-en-appliquant-des-règles-à-la-lettre.
Une fois de plus en matière de développement
"there is no silver bullet"...
|
| Tribune publiée par
Alain Lefebvre
le 14 mai 2003.
|
|
|
|
|
|
|
Au sommaire de l'actualité
- Toutes les Tribunes
|
|
|
|
