Jump to content
  • Advertisement
Sign in to follow this  
sofakng

How can I avoid this very simple (??) circular reference problem?

This topic is 4162 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Let's say I have two very simple classes: GameObject and GameObjectComponent Each GameObject has a list of GameObjectComponents. I'd like my GameObjectComponent to have a reference to the GameObject it currently "belongs" to. If these two classes are stored in different files then I have a circular reference problem. (eg. GameObject needs to know about GameObjectComponent, and GameObjectComponent needs to know about GameObject) What am I doing wrong? I really don't want to store these two classes in the same file...

Share this post


Link to post
Share on other sites
Advertisement
That's what pointers are for:

GameObjectComponent.h:

class GameObject; //note the ; -- this is a forward declaration

class GameObjectComponent
{
...
GameObject *parent; //note the * -- this makes it a pointer variable.
}

Share this post


Link to post
Share on other sites
Thanks for the reply...

I'm actually using a language called BlitzBASIC (eg. BlitzMax, www.blitzbasic.com).

Unfortunately it doesn't support compiler directives or forward declaration.

Sorry I didn't mention this in the original post, but I was wondering if I had a flaw in my design that was causing this...

Share this post


Link to post
Share on other sites
Quote:

Sorry I didn't mention this in the original post, but I was wondering if I had a flaw in my design that was causing this...


Yes, circular references are usually an indicator that something in the design could be better, but that's all I can say with the clues you've given us. Why the GameObjectComponent needs to know about its parent? For what services are you going to use GameObject from inside GameObjectComponent?

Share this post


Link to post
Share on other sites
If you can, you should avoid circular references from an OOP point of view. A GameObjectComponent that doesn't know about GameObject is more robust than one that does. This isn't always possible, though. Circular references do occur in well-designed systems. So no, your design is not necessarily flawed.

Share this post


Link to post
Share on other sites
Quote:
Original post by mikeman
Yes, circular references are usually an indicator that something in the design could be better, but that's all I can say with the clues you've given us. Why the GameObjectComponent needs to know about its parent? For what services are you going to use GameObject from inside GameObjectComponent?

Well, let's say I want to store a list of all renderable objects (eg. objects that have an IRenderable component [which is a class])

First off, should I store a list of IRenderable components or IGameObjects that support IRenderable?

Second, let's say components need to interact with each other. The only way for components to find out about each other are through the parent (eg. the GameObject).

With that said, do you see any problems in my design?

I've never design ANY game engine architecture, but building a component-based game engine sounds really nice and efficient so that's why I'm going with this design.

Thanks again for your help...

[EDIT] I'm also open to any component-based architecture design articles (for beginniners! Nothing extremely advanced, please...

Share this post


Link to post
Share on other sites
While Sneftel is certainly right that your design isn't necessarily bad, circular references are often classified as Code Smells.

I often have this problem as well; my designs typically have pointers to the Game object, which contains nearly everything else. Many people call this a God Object anti-pattern. It works well enough, but it prevents reuse and makes a tangled mess of object relationships. I often have to stop myself and try harder to make the relationships more one-way, so that lower-level objects don't have to "know" how they will be used.

Share this post


Link to post
Share on other sites
Quote:

Second, let's say components need to interact with each other. The only way for components to find out about each other are through the parent (eg. the GameObject).


Instead of having objects interact with each other, why not rely on the primary object (GameObject) to handle all the interactions between the components (GameObjectComponent)?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!