L'approche «d'agrégation pure» décrite par West dans cet article lié évite complètement un objet «entité». Il existe des composants flottant dans la mémoire, mais ils ne sont liés que par des relations implicites, voire pas du tout.
Une façon de procéder est une approche dite hors - bord . Dans un tel système, les composants sont détenus par des systèmes qui les gèrent ou les contrôlent d'une autre manière (j'utilise ici le terme "gérer", mais vous ne devriez pas considérer cela comme signifiant que je suggère que vous ayez un tas de classes * Manager à tenir types de composants). Par exemple, votre système physique peut s'accrocher à un tas de choses représentant chaque corps rigide dans son monde de simulation, et peut exposer ces choses en tant que composants physiques. Les composants peuvent être les objets réels gérés par le sous-système en question, ou ils peuvent être des proxys pour ces objets, selon les besoins.
Dans un tel système, il n'est pas nécessairement nécessaire qu'une classe "Entité" contienne une collection de références aux composants qui la composent; à la place, une notification est émise concernant la création ou la destruction d'une "entité" et chaque sous-système qui gère les composants examine la description de l'entité créée / détruite (qui est généralement chargée à partir de certaines données) et détermine si un composant est nécessaire pour cela.
L'un des avantages de cette approche est que vous obtenez une très bonne localité de référence pour chaque composant. Malheureusement, c'est un peu bizarre, dans l'ensemble, et ce n'est pas la saveur la plus conviviale des entités basées sur des composants que j'ai rencontrée. Parfois, il est vraiment pratique d'avoir un objet réel qui représente une entité, même si cet objet ne fait guère plus que d'agréger des références faibles à des composants qui sont toujours détenus par d'autres sous-systèmes (si rien d'autre, il fournit un moyen facile de router les messages entre les composants) .
Il existe plusieurs bonnes façons de mettre en œuvre des systèmes d'objets de jeu orientés composants; cela aide vraiment, vraiment, vraiment si vous avez une bonne idée des exigences que vous souhaitez retirer de votre système - vous pouvez voir ce que font les frameworks populaires comme Unity pour des exemples. Sans fixer des exigences strictes pour vous-même, vous pouvez rencontrer le problème de la «conception» sans fin du système sans jamais vraiment le construire, en essayant en vain de trouver la mise en œuvre parfaite. Pour une raison quelconque, je l'ai souvent vu avec les systèmes de composants.