POURQUOI ARC N'EST PAS PARTICULIÈREMENT ORIENTÉ OBJET

Janvier 2001

Il y a une sorte de manie pour la programmation orientée objet en ce moment, mais certains des programmers les plus intelligents que je connais 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 tous les programmes que vous écrivez. Vous devriez être en mesure de 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 et demie d'entre elles sont mauvaises :

La programmation orientée objet est excitante si vous avez un langage typé statiquement sans fermetures lexicales ou 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 façon dont elles écrivent les logiciels. Dans les grandes entreprises, les logiciels ont tendance à être écrits par de grandes équipes (et qui changent fréquemment) de programmeurs médiocres. La programmation orientée objet impose une discipline à ces programmeurs qui empêche l'un d'entre eux de faire trop de dégâts. Le prix à payer est que le code résultant est gonflé de protocoles et plein de duplications. Ce n'est pas un prix trop élevé pour les grandes entreprises, car leurs logiciels seront probablement gonflés et pleins de duplications de toute façon.

La programmation orientée objet génère beaucoup de ce qui ressemble à du travail. À l'époque des feuilles perforées, il existait un type de programmeur qui ne mettait que cinq ou dix lignes de code sur une page, précédées de vingt lignes de commentaires soigneusement formatés. 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 pirate 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. Eh bien, peut-être. Ou peut-être pouvez-vous faire encore mieux en offrant 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 correspondent 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 juste stupide, ou ai-je travaillé sur un sous-ensemble limité d'applications. Il y a un danger à concevoir un langage en fonction de sa propre expérience de la programmation. Mais il semble plus dangereux de mettre des choses que vous n'avez jamais eues besoin parce qu'on pense que c'est une bonne idée.