Component based is neither OO nor not-OO. It's a data design model (by segregation). And in the context of languages which don't support arbitrary containers natively, it's also a design pattern. [SnarkMode]It's yet another great idea from the same brain that came up with Objective-C. Although it was originally termed software ICs. Can't imagine why that didn't catch on.[/SnarkMode] It's a really fine idea. If you're writing, say, banking software..and especially if you choose a language well suited it. In the context of games? Almost always a huge waste of time except in the narrow case of needing to processing massive amounts of entities. At the same time. Which isn't necessarily the same has having a massive number of active entities. And even in that case I'm not sure it's a great idea. Because you can always build your system to use data segregation instead of creating/using some arbitrary container management system. As an aside, my guess is that most libraries are composition by type, rather than composition by name...meh.
The most recent discussion (that I recall) on this subject is here
in which I say this
. Actually Cas started a rant Still hardly any games, why entity systems suck, and why 4k is good
WRT: MappedObject. Faking structures is a great improvement, but you're still stuck for caching hints. And all of this is assuming that one did a good job of figuring out data segregation and maintain aux info to let you traverse the data linearity and not cause cache thrashing is some other core.
WRT: Cylabs pro list:
- flexible ... with respect to the one archtype, one class ultra deep rigid design pretty much only a beginner would do, then yeah...otherwise not really.
- easy to "glue in" third party libs (physics, etc.) ... don't see how this is true
- better "modding" support ... Pseudo-mixins and a basic extension mechanism cover pretty all your bases here and likewise these are 'at runtime' changes. If you wanted to get really fancy, you could add hot-deployment.
- better support for resource driven development ... don't see how this is true.