POURQUOI ARC N'EST PAS SPÉCIALEMENT ORIENTÉ OBJET

Janvier 2001

Il existe actuellement une sorte de manie pour la programmation orientée objet, mais certains des programmeurs les plus intelligents que je connaisse sont parmi les moins enthousiastes à ce sujet.

Mon sentiment personnel est que la programmation orientée objet est une technique utile dans certains cas, mais ce n'est pas quelque chose qui doit imprégner chaque programme que vous écrivez. Vous devriez pouvoir définir de nouveaux types, mais vous ne devriez pas avoir à exprimer chaque programme comme la définition de nouveaux types.

Je pense qu'il y a cinq raisons pour lesquelles les gens aiment la programmation orientée objet, et trois d'entre elles et demie sont mauvaises :

La programmation orientée objet est intéressante si vous disposez d'un langage typé statiquement sans fermetures lexicales ni macros. Dans une certaine mesure, elle offre un moyen de contourner ces limitations. (Voir la dixième règle de Greenspun .)

La programmation orientée objet est populaire dans les grandes entreprises, car elle convient à la manière dont elles écrivent leurs logiciels. Dans les grandes entreprises, les logiciels sont généralement écrits par de grandes équipes (qui changent fréquemment) de programmeurs médiocres. La programmation orientée objet impose à ces programmeurs une discipline qui empêche l'un d'entre eux de faire trop de dégâts. Le prix à payer est que le code qui en résulte est gonflé de protocoles et plein de doublons. Ce n'est pas un prix trop élevé pour les grandes entreprises, car leurs logiciels seront probablement gonflés et pleins de doublons de toute façon.

La programmation orientée objet génère beaucoup de travail. À l’époque des feuilles pliées en éventail, certains programmeurs ne mettaient que cinq ou dix lignes de code sur une page, précédées de vingt lignes de commentaires au format élaboré. La programmation orientée objet est comme du crack pour ces personnes : elle vous permet d’intégrer tout cet échafaudage directement dans votre code source. Quelque chose qu’un hacker Lisp pourrait gérer en poussant un symbole sur une liste devient un fichier entier de classes et de méthodes. C’est donc un bon outil si vous voulez vous convaincre, ou convaincre quelqu’un d’autre, que vous faites beaucoup de travail.

Si un langage est lui-même un programme orienté objet, il peut être étendu par les utilisateurs. Peut-être. Ou peut-être que l'on peut faire encore mieux en proposant les sous-concepts de la programmation orientée objet à la carte. La surcharge, par exemple, n'est pas intrinsèquement liée aux classes. Nous verrons.

Les abstractions orientées objet s'adaptent parfaitement aux domaines de certains types spécifiques de programmes, comme les simulations et les systèmes de CAO.

Personnellement, je n'ai jamais eu besoin d'abstractions orientées objet. Common Lisp possède un système d'objets extrêmement puissant et je ne l'ai jamais utilisé une seule fois. J'ai fait beaucoup de choses (par exemple, créer des tables de hachage pleines de fermetures) qui auraient nécessité des techniques orientées objet pour être réalisées dans des langages plus faibles, mais je n'ai jamais eu à utiliser CLOS.

Peut-être suis-je simplement stupide ou ai-je travaillé sur un sous-ensemble limité d'applications. Il y a un danger à concevoir un langage basé sur sa propre expérience de programmation. Mais il semble plus dangereux d'y mettre des choses dont on n'a jamais eu besoin parce qu'on pense que c'est une bonne idée.