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 programmeurs les plus intelligents que je connaisse sont parmi les moins enthousiastes à ce sujet.

Mon propre sentiment 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 et demi d'entre elles sont mauvaises :

La programmation orientée objet est excitante si vous avez un langage à typage statique 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 des logiciels. Dans les grandes entreprises, les logiciels ont tendance à être écrits par de grandes (et fréquemment changeantes) équipes de programmeurs médiocres. La programmation orientée objet impose une discipline à ces programmeurs qui les empêche de faire trop de dégâts. Le prix à payer est que le code qui en résulte est gonflé de protocoles et rempli de doublons. Ce n'est pas un prix trop élevé pour les grandes entreprises, car leurs logiciels seront probablement de toute façon gonflés et remplis de doublons.

La programmation orientée objet génère beaucoup de ce qui ressemble à du travail. À l'époque des listings continus, il y avait 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 élaborément formatés. La programmation orientée objet est comme de la cocaïne pour ces gens : elle vous permet d'incorporer 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 tout un fichier 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. Le surcharge, par exemple, n'est pas intrinsèquement lié aux classes. Nous verrons.

Les abstractions orientées objet se mapent bien sur les domaines de certains types de programmes spécifiques, comme les simulations et les systèmes CAO.

Personnellement, je n'ai jamais eu besoin d'abstractions orientées objet. Common Lisp a 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, remplir des tables de hachage de fermetures) qui auraient nécessité des techniques orientées objet dans des langages plus faibles, mais je n'ai jamais eu à utiliser CLOS.

Peut-être que je suis juste stupide, ou que j'ai travaillé sur un sous-ensemble limité d'applications. Il y a un danger à concevoir un langage en se basant uniquement sur sa propre expérience de la 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.