Kay no dijo que “C++ no sea OOP” en una definición formal; de hecho, en 1997 dijo que cuando acuñó object-oriented no tenía C++ en mente. Y en 2003 definió su propia concepción de OOP poniendo en el centro messaging, encapsulamiento del estado/proceso y extreme late-binding.
Cuando pensamos en Programación Orientada a Objetos, probablemente pensamos en algo así:
Clase
↓
Objeto
↓
Encapsulamiento
↓
Herencia
↓
Polimorfismo
Pensamos en class, extends, interfaces, métodos virtuales, getters, setters, jerarquías de tipos...
Y probablemente pensemos en lenguajes como C++, Java o C#.
Pero hay algo curioso: Esta no era exactamente la idea de Orientación a Objetos que tenía Alan Kay.
Y esto es especialmente interesante porque Alan Kay fue quien acuñó el término “object-oriented programming” mientras trabajaba en las ideas que terminarían dando lugar a Smalltalk.
Entonces vale la pena hacer una pregunta incómoda: ¿Qué tan lejos está la OOP que aprendimos de la OOP que Kay tenía en mente?
La enseñanza tradicional suele comenzar con:
Encapsulamiento
Abstracción
Herencia
Polimorfismo
Y después aparecen las clases:
class Dog extends Animal {
@Override
void speak() {
System.out.println("Woof");
}
}
Esto funciona perfectamente como modelo de programación.
Pero observemos algo:ninguna de estas ideas aparece como el centro de la definición que Kay dio de OOP.
En 2003, cuando le preguntaron qué significaba para él object-oriented programming, respondió:
“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”
Para Kay, el núcleo estaba en: messaging; mantener localmente el estado y proceso; proteger y ocultar ese estado; extreme late-binding.
No aparece: herencia; clases; jerarquías; interfaces; getters y setters.
Y esto no es una casualidad.
El objeto de Kay no es simplemente una estructura con métodos
Esta diferencia es fundamental.
Es común imaginar objetos como: datos + funciones asociadas a esos datos.
Kay tenía otra metáfora.
Pensaba los objetos como células biológicas o como computadoras individuales conectadas a una red: entidades independientes que poseen su propio estado y se comunican mediante mensajes.
Lo importante no es solamente qué objetos existen.
Lo importante es: cómo se comunican.
De hecho, Kay llegó a decir que lamentaba haber puesto tanto énfasis en la palabra objects, porque podía hacer que la gente se concentrara en la parte menos importante. Para él, “the big idea is messaging”.
Esta diferencia puede parecer sutil, pero es enorme.
En la forma habitual de pensar:
dog.speak();
tendemos a pensar: “Estoy invocando el método speak() de Dog.”
En el modelo de mensajes:
dog ← speak
la idea es más parecida a: “Le envío a este objeto el mensaje speak.”
No necesito conocer cómo responde.
Puede:
- ejecutar código local;
- cambiar su estado;
- delegar;
- enviar otro mensaje;
- crear otro objeto;
- incluso responder de una manera que yo no conocía cuando escribí el código.
El mensaje establece una frontera de comunicación.
Y ahí aparece el late binding.
En la OOP tradicional podemos tener:
Animal* animal = new Dog();
animal->speak();
y gracias a virtual, el método concreto se resuelve dinámicamente.
Eso ya es late binding.
Pero para Kay la idea debía llevarse mucho más lejos.
No se trata simplemente de decidir dinámicamente qué implementación de un método ejecutar.
Se trata de construir sistemas donde las partes estén desacopladas mediante mensajes y donde podamos cambiar las implementaciones sin que los demás componentes necesiten conocer esos detalles.
El mensaje define el contrato de comunicación.
La implementación queda detrás de esa frontera.
Acá aparece uno de los puntos más interesantes de toda esta discusión.
La OOP tradicional suele presentar:
Animal
/ \
Dog Cat
como algo central.
Pero la herencia no es necesaria en la definición de Kay.
Incluso en la historia temprana de estas ideas, la herencia no era necesariamente el punto de partida. El propio Kay explicó que hubo distintas líneas derivadas de Simula: una relacionada con el camino biológico/de redes que él siguió y otra relacionada con los abstract data types, que tuvo mucha más influencia posteriormente.
Es decir: La OOP que terminó popularizándose estuvo fuertemente influenciada por el modelo de clases y tipos, pero ese no era necesariamente el centro de la visión original de Kay.
Entonces apareció C++. Y acá podemos entender por qué C++ es tan importante en esta historia.
C++ hizo que la orientación a objetos se volviera masiva.
Pero la OOP de C++ está fuertemente expresada mediante:
classes
inheritance
virtual functions
types
access control
Es un modelo muy poderoso.
Pero no es exactamente la metáfora de:
computadoras independientes
↕
mensajes
↕
computadoras independientes
que inspiraba a Kay.
Por eso la pregunta no debería ser: ¿C++ está mal?
No.
La pregunta es: ¿C++ popularizó una interpretación particular de la orientación a objetos que terminó siendo confundida con la orientación a objetos en general?
Y probablemente esta sea una de las razones por las que hoy discutimos tanto si Rust, Go, JavaScript o incluso C son “orientados a objetos”.
Estamos utilizando una definición que mezcla diferentes tradiciones.
¿Y Smalltalk? Acá está la parte paradójica.
El lenguaje que nació de las ideas de Kay fue Smalltalk.
Y, sin embargo, incluso Smalltalk terminó desarrollando un fuerte énfasis en clases.
Kay llegó a aclarar que Smalltalk no debía entenderse simplemente como su sintaxis, su class library, ni siquiera como clases. Para él, el núcleo era el messaging.
Esto nos deja una idea bastante provocadora: Incluso el lenguaje que creó para explorar la orientación a objetos terminó siendo interpretado desde una perspectiva más centrada en clases de la que Kay consideraba fundamental.
Entonces, ¿qué es realmente OOP? Quizás después de todo este recorrido deberíamos volver a la pregunta original.
¿Es esto?
class
inheritance
encapsulation
polymorphism
¿O es esto?
objects
↕
messages
↕
objects
Kay parece inclinarse claramente por la segunda visión.
Su definición de OOP es deliberadamente pequeña: messaging, encapsulamiento del estado/proceso y late binding extremo.
Y esto cambia nuestra manera de mirar los lenguajes.
Un lenguaje puede tener clases y herencia y, aun así, utilizar una visión de objetos bastante diferente.
Y otro lenguaje puede no tener herencia y, sin embargo, compartir algunas ideas importantes con la orientación a objetos.
Por eso quizás la pregunta: “¿Rust es orientado a objetos?”
es menos interesante que: “¿Qué modelo de objetos utiliza Rust?”
Y lo mismo podemos preguntar de Go, C++, Java, C#, JavaScript o Smalltalk.
Tal vez la mayor diferencia entre la OOP tradicional y la visión de Kay sea esta:
La OOP tradicional nos enseñó a pensar en objetos como entidades que tienen datos y métodos.
Kay quería que pensáramos en objetos como pequeñas entidades autónomas que se comunican.
Una pone el foco en: ¿qué es este objeto?
La otra en ¿cómo se comunica este objeto con el resto del sistema?
Y esa diferencia no es menor.
Porque quizás la esencia de la orientación a objetos nunca estuvo en construir buenas jerarquías de clases.
Quizás estuvo, desde el principio, en diseñar buenas redes de comunicación entre entidades independientes.
Y si esto es así, entonces la pregunta que queda abierta es todavía más interesante:
¿Cuánto de la OOP que enseñamos hoy es realmente orientación a objetos y cuánto es simplemente programación basada en clases?
