Does your PositionBehavior have a list of all Positions components? if so then it can update them without getting them from the object itself.

This is how I do my component updates.

Why would it have to be a singleton?

When adding a component to a GameObject, add it to both the object, and the system responsible for updating it, keeping only a reference/pointer to the component in the system. If a GameObject gets deleted, make an event to each system telling it about the deletion so it can remove that objects' component from the list/vector/hashmap/whatever.

I do all of my component updating through the systems themselves. This makes sure that only those entities that have said component get updated and the order of updating. If there are messages to be handled, it's all done during that system's update.

My systems each contain a Dictionary<ulong, Component> (I'm using C#, so substitute whatever method you use) which holds the entity id (the ulong) and the component with the data associated with that system. This way, you shouldn't have to iterate over all of your entities because you already have a list of each component and the entity to which it belongs. I don't think, other than adding/removing a component, that I ever actually use the Entity objects themselves (I use the EntityManager class to handle messages, because each message type may have to be sent to multiple systems, so I just use it as a hub to send the messages to all applicable systems, though this may not be the most efficient way of handling this business).

Check out the articles in my signature for how I do my components. They're basically just arrays of components (one per type) and another array of component masks. An entity is the aggregation of all the elements at a given index in the arrays, where the component mask describes which components "exist" (are turned on).

It's cache friendly and requires no memory allocation past the initial allocation of the arrays.

Just for the record I haven't read post above (Boreal Games) when I wrote mine - now I did and it seems to be similar in approach to what I wrote in 2).

I can think of at least 3 approaches to this:

1) Registering components in corresponding systems so you don't have to query scene for objects that have component "Position" - system already has list of these components and its updated when object is added/removed from the scene. This is probably good approach if you plan to have hundreds of thousands of objects. Here you need to decide how component knows which system may be interested in having it - this may work on a listener basis where systems "listen" for certain components being either added/removed from object, or objects with components being added/removed from scene.

This approach requires that removing/adding is properly handled so you don't end up with systems keeping components that were removed, or their owners no longer exist.

2) Querying objects that meet component criteria, based on some "key". In my system I'm using a uint64 bit mask - when component is added to object, this objects sets a mask for component's family (family is a group of same-type components, for example Renderable is family sharing common interface that can be derived from to create TerrainRenderable etc.). When component is removed, it clears the mask. This allows me to know exactly what component types belong to a given game object - I don't have to retrieve exact component when I just need to gather objects that have for example Renderable and Spatial component.

When adding component to object:

m_CompMask |= static_cast<uint64_t>(family);

When checking if object has certain components, for example Comp::RENDERABLE and Comp::SPATIAL:

bool HasComponents(uint64_t mask)
{
      return (m_CompMask & mask) == mask;
}

if (obj->HasComponents(Comp::RENDERABLE | Comp::SPATIAL))
{
}

This way you can iterate over scene objects quite efficiently checking only bitmask. This still won't scale too well if you plan on having really A LOT of objects.

I use the second approach for scene on client-side where I don't really plan to have more than maybe few hundreds to a couple of thousands objects at any time. But for something like managing all game objects on some online game server side, this can easily go up to hundreds of thousands of objects and may be too slow - this is where I'd look into first method and register components in systems that require them.

3) System-ownership where systems are owners of components - if they own them, they already know about them so no need to query This may be best considering cache friendliness and speed, but gets complicated if there is system that works on more than 1 component - who owns such component then? Because of this I haven't tried this approach. In my case, object owns its components, and scene queries its objects for certain criteria. If I have render system that requires both - SPATIAL and RENDERABLE components on object, it can ask scene for them easily.