POR QUÉ ARC NO ESTÁ ESPECIALMENTE ORIENTADO A OBJETOS

Enero de 2001

Hay una especie de manía por la programación orientada a objetos en este momento, pero algunos de los programadores más inteligentes que conozco son algunos de los menos entusiasmados con ella.

Mi propia sensación es que la programación orientada a objetos es una técnica útil en algunos casos, pero no es algo que deba impregnar cada programa que escribas. Deberías poder definir nuevos tipos, pero no deberías tener que expresar cada programa como la definición de nuevos tipos.

Creo que hay cinco razones por las que a la gente le gusta la programación orientada a objetos, y tres y media de ellas son malas:

La programación orientada a objetos es interesante si se cuenta con un lenguaje de tipado estático sin cierres léxicos ni macros. Hasta cierto punto, ofrece una forma de sortear estas limitaciones (véase la décima regla de Greenspun ).

La programación orientada a objetos es popular en las grandes empresas, porque se adapta a la forma en que escriben software. En las grandes empresas, el software tiende a ser escrito por equipos grandes (y frecuentemente cambiantes) de programadores mediocres. La programación orientada a objetos impone una disciplina a estos programadores que evita que cualquiera de ellos haga demasiado daño. El precio es que el código resultante está inflado con protocolos y lleno de duplicaciones. Este no es un precio demasiado alto para las grandes empresas, porque su software probablemente estará inflado y lleno de duplicaciones de todos modos.

La programación orientada a objetos genera mucho trabajo. En la época del fanfold, había un tipo de programador que sólo ponía cinco o diez líneas de código en una página, precedidas por veinte líneas de comentarios con un formato elaborado. La programación orientada a objetos es como el crack para esta gente: te permite incorporar todo este andamiaje directamente en tu código fuente. Algo que un hacker de Lisp podría manejar insertando un símbolo en una lista se convierte en un archivo completo de clases y métodos. Por lo tanto, es una buena herramienta si quieres convencerte a ti mismo, o a alguien más, de que estás haciendo mucho trabajo.

Si un lenguaje es en sí mismo un programa orientado a objetos, los usuarios pueden extenderlo. Bueno, tal vez. O tal vez se pueda hacer algo aún mejor ofreciendo los subconceptos de la programación orientada a objetos a la carta. La sobrecarga, por ejemplo, no está intrínsecamente ligada a las clases. Ya veremos.

Las abstracciones orientadas a objetos se adaptan perfectamente a los dominios de ciertos tipos específicos de programas, como simulaciones y sistemas CAD.

Personalmente, nunca he necesitado abstracciones orientadas a objetos. Common Lisp tiene un sistema de objetos enormemente potente y nunca lo he usado. He hecho muchas cosas (por ejemplo, crear tablas hash llenas de cierres) que habrían requerido técnicas orientadas a objetos para hacerlas en lenguajes más débiles, pero nunca he tenido que usar CLOS.

Quizás soy un estúpido o he trabajado en un subconjunto limitado de aplicaciones. Existe un peligro en diseñar un lenguaje basado en la propia experiencia de programación. Pero parece más peligroso incluir cosas que nunca has necesitado porque se piensa que es una buena idea.