[dgb23]

Not sure I get what you mean. As I see it, ECS has more of a relational character. Feels more like data pipeline than operations/messages on objects. I think the mental model matters the most here and that depends on how you think of objects. But then any attempt of defining OO objectively seems to be futile, there are conflicting historical and contemporary notions plus a whole bunch of jargon on top, depending on who you're asking.

As an example you could say that Scheme is more object oriented than Java or vice versa and there would be valid, typically cultural reasons for each.

In terms of ECS what kind of happens is that, yes, you have a model of an entity and can think of that as an object, but that is a projection of a set of components or a relation. You're not really talking to the entity as a whole all that much anymore. And it's not just "it satisfies this set of interfaces" either. Your systems literally define data transformations, each on a focused set of related components that matter to a system, which seems kind of the inverse of hiding data behind object interfaces.

[pjmlp]

That is when data oriented programming gets into the equation.

Classical ECS as it originally appeared on the literature is coding against interfaces, COM or Objective-C protocols style.

So yeah, one composes those interfaces together, there is no class inheritance, only composition, delegation, and a system is composed from a jungle of such components.

It is also a reason why DirectX is COM based, instead of basic Win32 calls.

[ngrilly]

What do you mean by classical ECS? I’ve always read that the Entity-Component-System approach originated in the gaming industry, completely unrelated to what you wrote about COM, etc.

[pjmlp]

Yes, the famous GDC talk.

Usually most stuff in game development tends to be rediscovered, as most people don't come from CS backgrounds.