[Jtsummers]

> I've quickly realized that the authors have a concrete idea of what an object means to them. I was confused why their code was always so... “callback-y” and after studying it a little more, I've discovered the reason. I might have missed it, but I don't think they ever explicitly state it. All calls between objects are unidirectional: no public method of an actual object (not a plain data class) returns any value. They are always void methods. Objects don't “call” each other. They send a message and don't wait for a response. (Well, actually since they actually “send” it via method call, they do wait, but they pretend they don't.

https://en.wikipedia.org/wiki/Command–query_separation

https://martinfowler.com/bliki/CQRS.html

That sounds very much like Command-query separation or Command Query Responsibility Segregation to me. I haven't read this particular book (and almost certainly won't be getting to it within the next decade based on my ever increasing pile of unread books), but I wonder if they call this out. It's a critical decision in the architecture/design of a piece of software and it's worth stating that it's how they intend to design the system.

Coincidentally, to my mind, that model (CQS/CQRS) fits well with the blog author's idea of using an agent-based event system. Moving the objects into distinct threads of execution or processes, which also coincides with one of the intended ideas of OO by Alan Kay. OO-as-message-passing very much fits within the agent-based execution model.