POR QUE 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.

Minha própria sensação é que a programação orientada a objetos é uma técnica útil em alguns casos, mas não é algo que tenha que permear todos os programas 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 tipada estaticamente sem closures lexicais 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 grandes (e frequentemente em mudança) equipes de programadores medíocres. 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. Isso 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 trabalho. Nos dias 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 todo esse andaime diretamente no seu código-fonte. Algo que um hacker Lisp pode lidar empilhando um símbolo em uma lista se torna um arquivo inteiro de classes e métodos. Então é uma boa ferramenta se você quiser se convencer, ou convencer outra pessoa, de que está fazendo muito trabalho.

Se uma linguagem for ela mesma um programa orientado a objetos, ela pode ser estendida pelos usuários. Bem, talvez. Ou talvez você possa fazer ainda melhor oferecendo os subconceitos da programação orientada a objetos à la carte. A sobrecarga, por exemplo, não está intrinsecamente ligada às classes. Veremos.

As abstrações orientadas a objetos se mapeam perfeitamente para os domínios de certos tipos específicos de programas, como simulações e sistemas CAD.

Pessoalmente, nunca precisei de abstrações orientadas a objetos. Common Lisp tem um sistema de objetos incrivelmente poderoso e nunca o usei uma vez. 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 nunca precisei usar CLOS.

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