En los posts anteriores cuestionamos algunas ideas bastante instaladas sobre la Programación Orientada a Objetos.
¿Son realmente necesarios las clases y la herencia?
¿Los famosos cuatro pilares representan la esencia de OOP?
Y llegamos a una idea particularmente interesante al recuperar la visión de Alan Kay.
Para Kay, la esencia de OOP no estaba en las clases ni en la herencia.
En 2003 lo resumió así: “OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”
Es decir:
- mensajes;
- estado y comportamiento mantenidos localmente;
- protección y ocultamiento de ese estado;
- late binding extremo.
Y entonces aparece una pregunta sorprendente: ¿No se parece muchísimo esto al modelo de actores?
Kay imaginaba los objetos como entidades independientes, similares a células biológicas o pequeñas computadoras conectadas en una red.
Cada una tiene su propio estado y comportamiento y se comunica con las demás mediante mensajes.
Lo importante no es acceder al estado de otro objeto.
Lo importante es comunicarse con él.
Esto es muy diferente del modelo mental habitual de:
account.deposit(100);
donde tendemos a pensar en una llamada directa a un método.
En el modelo de mensajes, la idea fundamental es:
account ← deposit(100)
El receptor decide qué hacer con ese mensaje.
Y entonces aparecen los actores
Un actor tiene:
- estado;
- comportamiento;
- una dirección/referencia;
- un mailbox;
- capacidad para enviar mensajes;
- capacidad para cambiar su propio estado.
El actor recibe mensajes y, al procesarlos, puede modificar su estado y enviar nuevos mensajes.
Esto es exactamente el tipo de aislamiento que describe la idea de local retention de Kay.
En el modelo de actores de Akka, por ejemplo, el estado del actor está encapsulado detrás de una referencia: desde afuera no se puede acceder directamente a ese estado. Los demás actores solamente pueden interactuar enviándole mensajes.
En Erlang, la comunicación entre procesos se realiza mediante envío de mensajes, y el message passing es central en el modelo de concurrencia del lenguaje.
Podemos imaginar un proceso que mantiene su propio estado:
loop(State) ->
receive
{deposit, Amount} ->
loop(State + Amount);
{balance, From} ->
From ! {balance, State},
loop(State)
end.
El estado pertenece al proceso.
Otro proceso no hace:
process.state = 100
Tiene que enviarle un mensaje.
Esto produce una forma de encapsulamiento particularmente fuerte: No solamente ocultamos el estado; aislamos al propietario del estado.
Comparemos los dos modelos.
OOP tradicional
Object
├── state
└── methods
↑
│
otro objeto
│
method call
Modelo de actores
Actor A Actor B
┌───────────┐ ┌───────────┐
│ state │ │ state │
│ behavior │ │ behavior │
└─────┬─────┘ └─────┬─────┘
│ │
└──────── message ─────────────┘
En el segundo modelo no compartimos directamente el estado ni transferimos el flujo de ejecución al receptor.
Enviamos una señal y continuamos.
En Akka, por ejemplo, el envío de mensajes entre actores es asíncrono: el actor emisor no entrega su hilo de ejecución al receptor.
Esto hace que la metáfora de las “pequeñas computadoras que se comunican” resulte especialmente natural.
El encapsulamiento cambia de escala
En OOP tradicional podemos escribir:
class Account {
private BigDecimal balance;
public void deposit(BigDecimal amount) {
// ...
}
}
private protege el estado.
Pero el objeto sigue viviendo dentro del mismo espacio de ejecución y comparte muchas de las mismas estructuras que el resto del programa.
En un sistema de actores:
Actor A
│
│ message
▼
Actor B
B mantiene su estado aislado.
A no puede modificarlo directamente.
No hay:
B.balance = ...
La única forma de interactuar es mediante el protocolo de mensajes.
Y esto se acerca mucho a la idea de Kay: El objeto no expone su implementación; expone una forma de comunicarse.
¿Entonces Actor = Object?
No exactamente.
Esta es una distinción importante.
El modelo de actores es un modelo de computación concurrente con una semántica específica.
Los actores:
- procesan mensajes;
- tienen mailboxes;
- pueden ejecutarse concurrentemente;
- mantienen estado aislado;
- se comunican mediante mensajes.
Un objeto tradicional no necesita tener ninguna de esas propiedades.
Por ejemplo:
account.deposit(100);
puede ser una llamada síncrona y ejecutarse en el mismo hilo.
En cambio:
accountActor ! Deposit(100)
representa el envío de un mensaje a una entidad concurrente.
Por lo tanto: Actor y objeto no son sinónimos.
Pero hay una coincidencia conceptual extraordinariamente fuerte.
Para la OOP tradicional:
objeto → método
suele ser el centro del modelo mental.
Para Alan Kay:
objeto → mensaje → objeto
es mucho más importante.
Para los actores:
actor → mensaje → actor
es literalmente el mecanismo fundamental de comunicación.
El modelo de actores no es una implementación de la OOP de Kay.
Pero comparte con ella una idea que resulta mucho más fundamental que las clases y la herencia: las entidades encapsuladas se relacionan mediante mensajes.
En los lenguajes OO tradicionales solemos enseñar:
- Encapsulamiento
- Abstracción
- Herencia
- Polimorfismo
Pero el modelo de actores nos permite pensar otra lista:
- Estado privado
- Comportamiento
- Mensajes
- Aislamiento
- Concurrencia
Y sorprendentemente, esta segunda lista está mucho más cerca de la definición que Kay daba de OOP.
De hecho, la documentación de Akka llega a describir a los actores como objetos que encapsulan estado y comportamiento y se comunican exclusivamente mediante mensajes.
Podemos plantear una hipótesis interesante: El modelo de actores puede ser una realización especialmente cercana a la visión original de Alan Kay de entidades autónomas que mantienen su propio estado y se comunican mediante mensajes.
Incluso podemos decir que lleva algunas de esas ideas más lejos.
En OOP tradicional:
objeto
│
└── mensaje
En actores:
actor
│
├── mailbox
├── estado privado
├── comportamiento
└── mensajes
Y además aparece algo que Kay consideraba fundamental: el desacoplamiento.
El emisor no necesita conocer cómo funciona internamente el receptor.
Solo necesita conocer cómo comunicarse con él.
Después de todo este recorrido, tal vez ya no tenga demasiado sentido preguntar: “¿Los actores son orientación a objetos?”
La pregunta más interesante sería: ¿Qué pasa si tomamos en serio la idea de que OOP es fundamentalmente comunicación entre entidades encapsuladas?
Ahí Erlang y los sistemas de actores dejan de parecer una idea completamente separada de OOP.
Y aparecen como otra manera de explorar una intuición muy antigua:
Entidad
│
│
mensaje
│
▼
Entidad
No clases.
No necesariamente herencia.
No necesariamente jerarquías.
Comunicación.
Quizás eso sea justamente lo que Alan Kay quería decir cuando afirmó que el núcleo de Smalltalk no eran las clases, sino messaging.
Y entonces queda una pregunta fascinante: ¿Y si el modelo de actores no estuviera tan lejos de la Orientación a Objetos como creemos, sino que estuviera recuperando precisamente una parte de OOP que el modelo tradicional de clases terminó dejando en segundo plano?
.jpeg)
