POR QUE O ARC NÃO É ESPECIALMENTE ORIENTADO A OBJETOS

Janeiro de 2001

Há uma espécie de mania por programação orientada a objetos no momento, mas alguns dos programadores mais inteligentes que conheço são alguns dos menos empolgados com isso.

Minha própria sensação é que a programação orientada a objetos é uma técnica útil em alguns casos, mas não é algo que precisa permeiar cada programa que você escreve. Você deve ser capaz de definir novos tipos, mas não deve ter que expressar cada programa como a definição de novos tipos.

Acho que há cinco razões pelas quais as pessoas gostam de programação orientada a objetos, e três delas são ruins:

A programação orientada a objetos é empolgante se você tem uma linguagem de tipagem estática sem fechamentos lexicais ou macros. Até certo ponto, oferece uma maneira de contornar essas limitações. (Veja A Décima Regra de Greenspun.)

A programação orientada a objetos é popular em grandes empresas, porque se adapta à maneira como elas escrevem software. Em grandes empresas, o software tende a ser escrito por grandes (e frequentemente mudando) equipes de programadores medianos. A programação orientada a objetos impõe uma disciplina a esses programadores que impede que qualquer um deles cause muito dano. O preço é que o código resultante é inchado com protocolos e cheio de duplicação. Este não é um preço muito alto para grandes empresas, porque seu software provavelmente vai ser inchado e cheio de duplicação de qualquer maneira.

A programação orientada a objetos gera muito do que parece trabalho. Nos dias do papel em fanfold, havia um tipo de programador que só colocava cinco ou dez linhas de código em uma página, precedidas por vinte linhas de comentários elaboradamente formatados. A programação orientada a objetos é como crack para essas pessoas: permite que você incorpore toda essa estrutura diretamente no seu código-fonte. Algo que um hacker de Lisp poderia lidar empurrando um símbolo para uma lista se torna um arquivo inteiro de classes e métodos. Portanto, é uma boa ferramenta se você quiser se convencer, ou a outra pessoa, de que está fazendo muito trabalho.

Se uma linguagem é ela mesma um programa orientado a objetos, pode ser estendida pelos usuários. Bem, talvez. Ou talvez você possa fazer ainda melhor oferecendo os sub-conceitos da programação orientada a objetos à la carte. Sobrecarga, por exemplo, não está intrinsecamente ligada a classes. Vamos ver.

As abstrações orientadas a objetos se mapeiam bem nos domínios de certos tipos específicos de programas, como simulações e sistemas CAD.

Pessoalmente, nunca precisei de abstrações orientadas a objetos. O Common Lisp tem um sistema de objetos enormemente poderoso e eu nunca o usei uma vez. Fiz muitas coisas (por exemplo, criando tabelas hash cheias de fechamentos) que teriam exigido técnicas orientadas a objetos para serem feitas em linguagens mais fracas, mas nunca precisei usar o CLOS.

Talvez eu seja apenas estúpido, ou tenha trabalhado em algum subconjunto limitado de aplicações. Há um perigo em projetar uma linguagem com base na própria experiência de programação. Mas parece mais perigoso colocar coisas que você nunca precisou porque se pensa que é uma boa ideia.