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 os menos animados 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 tem que permear todos os programas que você escreve. Você deve ser capaz de definir novos tipos, mas não deve ter que expressar todos os programas como a definição de novos tipos.

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

A programação orientada a objetos é emocionante se você tem uma linguagem estaticamente tipada sem fechamentos lexicais ou macros. Até certo ponto, ela 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 medíocres. A programação orientada a objetos impõe uma disciplina a esses programadores que impede qualquer um deles de causar 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 será inchado e cheio de duplicação de qualquer maneira.

A programação orientada a objetos gera muito do que parece ser trabalho. Na época do fanfold, havia um tipo de programador que colocava apenas 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: ela permite que você incorpore todo esse andaime diretamente no seu código-fonte. Algo que um hacker Lisp pode manipular ao empurrar um símbolo para uma lista se torna um arquivo inteiro de classes e métodos. Então é uma boa ferramenta se você quiser convencer a si mesmo, ou a outra pessoa, de que está fazendo muito trabalho.

Se uma linguagem é em si um programa orientado a objetos, ela pode ser estendida pelos usuários. Bem, talvez. Ou talvez você possa fazer ainda melhor oferecendo os subconceitos de programação orientada a objetos a la carte. Sobrecarga, por exemplo, não está intrinsecamente ligada a classes. Veremos.

Abstrações orientadas a objetos mapeiam perfeitamente os domínios de certos tipos específicos de programas, como simulações e sistemas CAD.

Eu, 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. Eu fiz muitas coisas (por exemplo, fazer tabelas hash cheias de closures) que teriam exigido técnicas orientadas a objetos para fazer em linguagens mais fracas, mas eu nunca precisei usar CLOS.

Talvez eu seja apenas estúpido, ou tenha trabalhado em algum subconjunto limitado de aplicativos. 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 é considerado uma boa ideia.