logo
2024-08-26
4 minutos de lectura

El Fiasco de la Programación Orientada a Objetos

La Historia de Alan Kay y la Crítica al Paradigma

monográficos
miniatura del artículo

La Programación Orientada a Objetos (POO) ha sido durante décadas considerada como el pináculo de la organización del código en el desarrollo de software. Muchos la ven como la solución definitiva para manejar la complejidad de grandes proyectos de software. Sin embargo, lo que comenzó como una gran promesa, se ha convertido para algunos en una trampa que ha costado miles de millones de dólares en tiempo y esfuerzo malgastados.

Para entender cómo llegamos aquí, es esencial conocer a Alan Kay, una figura clave en el desarrollo de la POO. A menudo desconocido fuera de los círculos especializados, Kay es un pionero en la informática cuyo trabajo en los años 60 y 70 sentó las bases para lo que hoy conocemos como POO. Su trayectoria está llena de momentos fortuitos que lo llevaron a convertirse en uno de los pensadores más influyentes en su campo.

La POO, como concepto, surgió de la necesidad de encontrar una mejor manera de modular y organizar el código en proyectos de software cada vez más complejos. La idea era simple pero poderosa: en lugar de dividir el código en funciones y procedimientos, ¿por qué no dividirlo en "pequeñas computadoras" que se comunican entre sí mediante el envío de mensajes?

La Evolución de la POO y su Implementación en Lenguajes Populares

El primer lenguaje que reflejó estas ideas fue Smalltalk, desarrollado por Kay en Xerox durante los años 70. Smalltalk fue diseñado para ser un lenguaje accesible y potente, y sentó las bases para la POO tal y como la conocemos. Sin embargo, con el tiempo, otros lenguajes como C++ y Java adoptaron e implementaron la POO de maneras que, según Kay, distorsionaron su visión original.

Bjarne Stroustrup, creador de C++, afirmó que su lenguaje no era puramente orientado a objetos, sino que permitía el uso de POO junto con otros paradigmas. Esta flexibilidad, aunque útil, también ha sido criticada por llevar a implementaciones que no cumplen con las promesas originales de modularidad y simplicidad.

Críticas y Desilusiones: El "Desastre del Billón de Dólares"

A lo largo de los años, la POO ha sido objeto de severas críticas. Ingenieros de software como Edsger Dijkstra y Linus Torvalds han expresado su desaprobación hacia la POO, especialmente en su implementación en lenguajes como C++ y Java.

Para algunos, la POO ha llevado a una sobrecarga de abstracciones, haciendo que el código sea más difícil de entender, mantener y depurar.

Joe Armstrong, creador de Erlang, criticó la POO por su falta de restricciones adecuadas y por no cumplir con sus promesas de mejor reutilización de código. Según Armstrong, los desarrolladores a menudo se ven obligados a cargar con una enorme cantidad de código innecesario simplemente para reutilizar una pequeña parte de él.

Incluso Alan Kay, quien acuñó el término "Programación Orientada a Objetos", ha expresado su descontento con la dirección que ha tomado el paradigma, señalando que lenguajes como Java son "lo más angustioso que le ha sucedido a la informática desde MS-DOS".

Para entender mejor toda esta historia...

La Programación Orientada a Objetos es un paradigma de programación que se basa en el concepto de "objetos". Un objeto es una entidad que combina tanto datos como comportamientos. Los datos se representan a través de atributos (o propiedades), y los comportamientos se definen mediante métodos (o funciones).

Componentes principales de la POO

  1. Clases: Una clase es como un molde o plantilla a partir de la cual se crean objetos. Define los atributos y métodos que tendrán los objetos creados a partir de ella. Por ejemplo, si tienes una clase Coche, podría tener atributos como color, marca y modelo, y métodos como acelerar y frenar.

  2. Objetos: Un objeto es una instancia de una clase. Si Coche es la clase, un objeto sería un coche específico, como un Coche rojo de marca Toyota. Cada objeto tiene su propio estado, definido por los valores de sus atributos.

  3. Encapsulamiento: Es la idea de ocultar los detalles internos de un objeto y exponer solo lo necesario. Esto se hace para proteger los datos y evitar que el estado interno del objeto sea modificado de manera incorrecta.

  4. Herencia: Permite crear nuevas clases a partir de clases existentes, heredando sus atributos y métodos. Por ejemplo, podrías tener una clase Vehículo, y Coche podría ser una subclase que herede características de Vehículo.

  5. Polimorfismo: Es la capacidad de los objetos de diferentes clases de ser tratados como objetos de una clase común. Más específicamente, es cuando un mismo método puede tener diferentes implementaciones según el objeto que lo esté utilizando.

Conclusión

La pregunta que queda es si la POO, tal y como se practica hoy en día, ha sido un fracaso. ¿Es realmente un "desastre de billones de dólares" o simplemente un malentendido de los principios originales de Kay? Aunque las críticas son válidas, es importante recordar que la POO también ha permitido avances significativos en la forma en que escribimos software.

El verdadero problema puede no ser la POO en sí, sino cómo se ha implementado y enseñado. Tal vez, como sugirió Kay, el foco debería estar más en la mensajería entre objetos que en los objetos mismos. Al final, la POO, como cualquier otro paradigma, tiene sus pros y contras, y depende de los desarrolladores utilizarla de manera que maximice sus beneficios y minimice sus desventajas.

Fuentes: