POR QUÉ ARC NO ES 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 emocionante si tienes un lenguaje de tipo estático sin cierres léxicos o macros. Hasta cierto punto, ofrece una forma de sortear estas limitaciones. (Ver La décima regla de Greenspun.)

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

La programación orientada a objetos genera mucho de lo que parece trabajo. En los días del papel en acordeón, había un tipo de programador que solo ponía cinco o diez líneas de código en una página, precedidas por veinte líneas de comentarios elaboradamente formateados. La programación orientada a objetos es como crack para estas personas: te permite incorporar toda esta estructura directamente en tu código fuente. Algo que un hacker de Lisp podría manejar al empujar un símbolo a una lista se convierte en un archivo completo de clases y métodos. Así que 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, puede ser extendido por los usuarios. Bueno, tal vez. O tal vez puedes hacerlo 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. Veremos.

Las abstracciones orientadas a objetos se mapean perfectamente en 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 poderoso y nunca lo he utilizado una vez. He hecho muchas cosas (por ejemplo, crear tablas hash llenas de cierres) que habrían requerido técnicas orientadas a objetos para hacer en lenguajes más débiles, pero nunca he tenido que usar CLOS.

Quizás solo soy estúpido, o he trabajado en un subconjunto limitado de aplicaciones. Hay 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.