EL PORQUÉ ARC NO ESTA ESPECIALMENTE ORIENTADO A OBJETOS


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 de los menos entusiasmados por ello.

Mi propio sentir es que la programación orientada a objetos es una técnica útil en algunos casos, pero no es algo que deba impregnar todos los programas que escribes. Debes ser capaz de 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 las personas les gusta la programación orientada a objetos, y tres y media de ellas están mal:

  1. La programación orientada a objetos es emocionante si tienes un lenguaje de tipo estático, sin clausuras léxicas o macros. Hasta cierto punto, ofrece una forma de evitar estas limitaciones. (Ver la Regla Décima de Greenspun.)
  1. La programación orientada a objetos es muy 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 que cambian con frecuencia) de programadores mediocres. La programación orientada a objetos impone una disciplina en estos programadores que impide que cualquiera de ellos haga mucho daño. El precio es que el código resultante esta inflado con protocolos y lleno de duplicidades. Este no es un precio demasiado alto para las grandes empresas, debido a que su software estará, de todas maneras, probablemente inflado y lleno de duplicidades.
  1. La programación orientada a objetos genera una gran cantidad de lo que luce como trabajo. En aquellos días cuando todavía se imprimía con matriz de punto, había un tipo de programador que sólo pondría cinco o diez líneas de código en una página, precedido por veinte líneas de comentarios elaboradamente formateados. La programación orientada a objetos es como el crack para esta gente: le permite incorporar todo este andamiaje justo en su código fuente. Algo que un hacker de Lisp puede manejar insertando un símbolo en una lista se convierte en un archivo completo de clases y métodos. Asi que es una buena herramienta si quieres convencerte a ti mismo, o a alguien más, de que estás trabajando mucho.
  1. 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 a la carta los sub-conceptos de la programación orientada a objetos. La sobrecarga, por ejemplo, no está intrínsecamente ligada a las clases. Veremos.
  1. Las abstracciones orientadas a objetos se mapean perfectamente en los dominios de ciertos tipos específicos de programas, como las simulaciones y los sistemas CAD.

Yo personalmente nunca he necesitado abstracciones orientadas a objetos. Common Lisp tiene un sistema de objetos muy poderoso y nunca lo he usado una sola vez. He hecho muchas cosas (por ejemplo, crear tablas de hashs llenas de clausuras) que habrían requerido técnicas orientadas a objetos en lenguajes mas endebles, pero nunca he tenido que usar CLOS.

Quizás sólo soy estúpido, o he trabajado en algún subconjunto limitado de aplicaciones. Es peligroso diseñar un lenguaje basado en la propia experiencia de la programación. Sin embargo, parece más peligroso poner cosas que nunca necesitaste por considerar que es una buena idea.




Traducido de Why Arc Isn't Especially Object-Oriented por Paul Graham. Traducción: Armando Alvarez