La esencia de la OOP es la mensajería: la verdadera OOP según Alan Kay
Al estudiar OOP, siempre empezamos memorizando tres palabras: herencia, encapsulación y polimorfismo.
Sin embargo, Alan Kay, quien acuñó el término «programación orientada a objetos», no consideraba esas tres ideas el núcleo.
La idea clave es esta: la esencia de la verdadera OOP, según Alan Kay, son los mensajes que circulan entre objetos, no los objetos en sí. Importa antes qué intercambian los objetos que cómo dividimos las clases.
Al terminar entenderás por qué llegó a decir que «se arrepentía del nombre orientado a objetos» y cómo esta perspectiva cambia nuestro código.
¿Por qué Alan Kay se arrepintió del nombre «OOP»?
Alan Kay creó Smalltalk en Xerox PARC durante la década de 1970. El término «programación orientada a objetos» surgió de él.
En 2003, cuando un desarrollador le preguntó por correo electrónico qué era la OOP, respondió:
«Me arrepiento de haber usado la palabra “objeto”.
Hizo que la gente se centrara en un concepto menos importante. La idea realmente grande es la “mensajería”.»
La primera vez que lees esto resulta desconcertante. Lo que aprendimos como OOP siempre fue «cómo diseñar bien los objetos».
Para Kay, lo verdaderamente importante no estaba dentro de los objetos. Eran las relaciones e interacciones que forman al intercambiar mensajes: esa es la esencia del sistema.
Comparó los programas con células biológicas. Cada célula oculta su interior y se comunica únicamente mediante señales químicas, es decir, mensajes. Internet funciona igual: innumerables ordenadores operan de forma independiente e intercambian solo mensajes.
¿Qué diferencia aporta pensar en los mensajes?
«Llamar a un método» y «enviar un mensaje» parecen similares, pero la perspectiva es distinta.
Una llamada a método se parece a «ejecuta esta función de este objeto». El emisor debe conocer hasta cierto punto el interior del receptor.
Un mensaje, en cambio, se parece a «encárgate de esto; tú decides cómo». El emisor solo quiere el resultado y no necesita saber cómo lo procesa la otra parte.
Veamos un ejemplo. Este código delega el cálculo del descuento en cada objeto de nivel de membresía mediante un «mensaje».
protocol Member {
func discountedPrice(for price: Int) -> Int
}
struct Gold: Member {
func discountedPrice(for price: Int) -> Int { price * 80 / 100 }
}
struct Silver: Member {
func discountedPrice(for price: Int) -> Int { price * 90 / 100 }
}
// El emisor desconoce por completo el cálculo de cada nivel.
let members: [Member] = [Gold(), Silver()]
for m in members {
print(m.discountedPrice(for: 10000))
}
// Salida: 8000
// Salida: 9000El código que realiza la llamada no contiene ningún if ni nombres de niveles.
Solo envía el mensaje «calcula el precio con descuento»; cada objeto se encarga del cálculo real. Aunque aparezca un nivel nuevo, no hay que tocar el código llamador.
Ese es el poder de la mensajería del que hablaba Kay. El objetivo no es dividir los objetos en piezas pequeñas, sino una forma de comunicación que reduce el acoplamiento.
Entonces, ¿no hacen falta la encapsulación ni el polimorfismo?
No. Más bien al contrario.
Si te tomas en serio la mensajería, la encapsulación y el polimorfismo aparecen de forma natural.
Para comunicarse únicamente mediante mensajes, los objetos deben ocultar su estado interno. Eso es la encapsulación. Que cada objeto responda de forma distinta al mismo mensaje es el polimorfismo.
No son reglas que haya que memorizar, sino resultados que aparecen naturalmente al diseñar centrados en los mensajes.
El problema está en el orden. Mucha gente empieza con «dividamos bien las clases». Así aparecen muchos objetos, pero también código que se asoma al interior de los demás y es orientado a objetos solo de nombre.
La perspectiva de Kay invierte el orden. Primero pregunta: «¿A qué mensajes debe responder este objeto?»
¿Cuándo conviene usar esta perspectiva y cuándo quitarle intensidad?
El diseño centrado en mensajes no siempre es la respuesta correcta. Lo importante es usarlo según la situación.
| Situación | Criterio |
|---|---|
| Lógica de dominio con requisitos que cambian a menudo | Conviene estructurar la delegación alrededor de mensajes |
| Flujos complejos con muchos objetos colaboradores | Muy eficaz para reducir el acoplamiento |
| Scripts sencillos de transformación o cálculo de datos | Usa funciones en lugar de envolverlos innecesariamente en objetos |
| Secciones donde el rendimiento es extremadamente importante | Una abstracción excesiva puede convertirse en una carga |
En resumen:
- Cuanta más colaboración y cambio haya, más valor aporta la perspectiva de los mensajes.
- Para una lógica sencilla y fija, es mejor mantenerla ligera.
- Recuerda que el objetivo no es «dividir objetos», sino «diseñar la comunicación».
Así lo preguntan en las entrevistas
P. ¿Cuál es la esencia de la OOP según Alan Kay?
No son los objetos en sí, sino los mensajes que circulan entre ellos. Kay comparó los objetos con células que se comunican de forma independiente y consideró la mensajería una idea más grande que la herencia o la encapsulación.
P. ¿Qué ventajas prácticas ofrece el diseño centrado en mensajes?
El código llamador no necesita conocer la implementación interna del receptor, por lo que se reduce el acoplamiento. Así, añadir un tipo nuevo no exige modificarlo y la estructura resiste mejor los cambios.
Si la OOP te resulta difícil, antes de dibujar un diagrama de clases pregúntate: «¿Qué se están diciendo estos objetos?»
Basta cambiar una perspectiva para notar que el código se vuelve mucho más sólido. ¡Que sigas diseñando bien!