In the past couple of months, I’ve been trying to critically think about how Alan Kay said OOP is really about the messages being passed, not the objects, a sentiment echoed in part by Sandi Metz in her workshops. I decided on a constraining definition of OOP, “Messages are passed to an unknown receiver from a known sender,” and eventually drew up something like the initial sketch in the linked document. I realized I was looking at something like the actor model used by Erlang; inbox messages are literally just labels, as I understand it, and the actor operates on the message labels it knows about. I remember reading a few opinion pieces on how Erlang implements OOP as Kay intended it, so I felt like I was on the right track.
But this isn’t quite like the actor model used in Erlang; as I understand it, each actor in Erlang has its own inbox and message passing is one-way. In this sketch, there’s instead a central inbox that all other objects are tightly coupled to; the central inbox’s public api is restricted to
get, which takes a message label, and
post, which takes a message object. Worker units can
get message objects per labels they know, then perform work; source units can
post message objects they know, and source units can also be workers or strictly just producers via Kafka, Redis, etc.
Message objects can have multiple rule objects associated with them; for instance, an ArrayMessage could say, “When a source
posts this type of message, append it to an array; when a worker
gets this type, return the entire array”; a StackMessage pushes and pops; a DelayedMessage instructs the inbox to return an error object if the minimum delay between
gets hasn’t been reached; etc.
There’s nothing new under the sun, so this exists somewhere; I just don’t know what it is or how exactly to search for it, so I thought I could pick the brains of @Freemo and company.