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

Janeiro de 2001

Existe 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 entusiasmados com isso.

Meu próprio sentimento é que a programação orientada a objetos é uma técnica útil em alguns casos, mas não é algo que precisa permear 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 existem cinco razões pelas quais as pessoas gostam da programação orientada a objetos, e três e meia delas são ruins:

A programação orientada a objetos é emocionante se você tiver uma linguagem estaticamente tipada sem fechamentos léxicos ou macros. Em certa medida, 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 equipes grandes (e frequentemente em mudança) 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. Esse não é um preço muito alto para as 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 trabalho. Nos tempos do 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 em seu código-fonte. Algo que um hacker de Lisp poderia resolver empurrando 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 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 subconcei tos da programação orientada a objetos à la carte. O overloading, por exemplo, não está intrinsecamente ligado a classes. Veremos.

As abstrações orientadas a objetos se encaixam perfeitamente 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 nunca o usei nem uma vez. Fiz muitas coisas (por exemplo, criar tabelas hash cheias de fechamentos) que teriam exigido técnicas orientadas a objetos para fazer em linguagens mais fracas, mas nunca tive que usar o CLOS.

Talvez eu seja apenas estúpido ou tenha trabalhado em um 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 se pensa que é uma boa ideia.