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 al respecto.

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 tenga que 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 tipado estático sin cierres léxicos o macros. En cierta medida, 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 con frecuencia cambiantes) de programadores mediocres. La programación orientada a objetos impone una disciplina a estos programadores que evita que cualquiera de ellos cause demasiados daños. El precio es que el código resultante está hinchado de protocolos y lleno de duplicación. Este no es un precio demasiado alto para las grandes empresas, porque su software probablemente será hinchado y estará lleno de duplicación de todos modos.

La programación orientada a objetos genera mucho de lo que parece trabajo. En los tiempos de las hojas continuas, 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 con un formato elaborado. La programación orientada a objetos es como la cocaína para estas personas: les permite incorporar todo este andamiaje directamente en su código fuente. Algo que un hacker de Lisp podría manejar empujando un símbolo a una lista se convierte en todo un archivo 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 ampliado por los usuarios. Bueno, tal vez. O tal vez puedas hacerlo aún mejor ofreciendo los subconceptos de la programación orientada a objetos a la carta. El sobrecargado, por ejemplo, no está intrínsecamente ligado a las clases. Ya veremos.

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

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

Tal vez soy solo un 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 poner cosas que nunca has necesitado porque se piensa que es una buena idea.