Earlier quoted context omitted.
I wrote a chapter on that too! http://gameprogrammingpatterns.com/component.html
You might want to look at how people are approaching components now. Instead of components containing logic, components only contain data. You then have systems that operate on the components. This solves the problem of needing components to interact with each other, since a system can look at as many components as it wants. https://en.wikipedia.org/wiki/Entity_component_system http://t-machine.org/index.php/2007/11/…
I say seems to be because while ECS is clearly being talked about a lot, I'm not sure how many shipped games are actually architected around it. The blogosphere doesn't always accurately reflect reality.
I've looked at a few ECS implementations and many of the ones I saw had such bizarre implementations that they more than nullified the performance benefits of components.
I do see the advantage of systems that work on multiple components, but I think some proponents are starting to cargo cult this model. That happens frequently in games because you have so many amateurs that want to know the "best" way to do things, and the constraints are challenging.
Hmm, this ended up sounding overly negative which I didn't intend. I think ECS is interesting, but I'll be interested to see how it matures over time. Right now it feels a bit like the OOP fads of the 90s to me. There's good ideas in it, but any good idea can be taken too far.