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

January 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 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 être capable 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 à 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 équipes (et souvent changeantes) de programmeurs médiocres. La programmation orientée objet impose une discipline à ces programmeurs qui empêche l'un d'eux de causer 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 leur logiciel sera probablement gonflé et plein 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 en accordéon, 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és. La programmation orientée objet est comme de la drogue pour ces personnes : elle vous permet d'incorporer tout ce scaffolding 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. Donc, c'est 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 que vous pouvez faire encore mieux en offrant les sous-concepts de la programmation orientée objet à la carte. Le surchargement, par exemple, n'est pas intrinsèquement lié aux classes. Nous verrons.

Les abstractions orientées objet se cartographient parfaitement sur les domaines de certains types spécifiques de programmes, 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, créer des tables de hachage pleines de fermetures) qui auraient nécessité des techniques orientées objet à faire 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 basé sur sa propre expérience de programmation. Mais il semble plus dangereux d'inclure des éléments dont vous n'avez jamais eu besoin parce qu'on pense que c'est une bonne idée.