Jump to content
  • Advertisement
Sign in to follow this  
RyanZec

circular dependencies problem

This topic is 4020 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

Here is my problem: I have 2 class, a player class and a party class. Now I want the both following statements to work: small_party->add_player(eridius); blixs->join_party(small_party); The problem is that player need to know about party and party needs to know about player which creates circular dependencies, which I hear is bad coding. I was thinking about adding a party_manager class but all the would do is just create an interface for both party and player but the same circular dependencies would still be there. Is there any way of having both party and player to be able to join/add( and leave/kick) and party without circular dependencies?

Share this post


Link to post
Share on other sites
Advertisement
nb, erissian: Thats not what he asked, he asked how to avoid circular dependencies. As in how to design the system so that there arnt any circular dependencies. Not how to overcome the problems associated with c++'s compilation modal.

RyanZec: To give a good answer we need to know more about what you want to do with the player and party class, What exactly do the player and part class do? As it stands I'm suspect of the player class as its not obvious from the name what it does and hence I suspect it does multiple things which would violate the Single Responsibility Principle.

Share this post


Link to post
Share on other sites
It's a typical A <=> B situation. It's broken by cutting up A into A1 and A2, where A1 <- B <- A2 and A2 inherits from A1. In short:

Create a character module. It does not know about players or parties.

Create a party module. It knows about characters, which can be made part of parties.

Create a player module, usable as a character, which knows about parties (that it can choose to join).

This also lets you have other characters (such as mules or henchmen) that are not players and can be placed inside a party.

Share this post


Link to post
Share on other sites
Quote:
Original post by Julian90
nb, erissian: Thats not what he asked, he asked how to avoid circular dependencies. As in how to design the system so that there arnt any circular dependencies. Not how to overcome the problems associated with c++'s compilation modal.

RyanZec: To give a good answer we need to know more about what you want to do with the player and party class, What exactly do the player and part class do? As it stands I'm suspect of the player class as its not obvious from the name what it does and hence I suspect it does multiple things which would violate the Single Responsibility Principle.


Well the player class in not responsible for anything dealing with the adding players/kicking of players but I do want to have the player to be able to store a pointer to it own party.

Share this post


Link to post
Share on other sites
Quote:
Original post by RyanZec
Well the player class in not responsible for anything dealing with the adding players/kicking of players but I do want to have the player to be able to store a pointer to it own party.


First, ask yourself why - i.e., what will the player do with this pointer? Why does the player need to know what party s/he's currently in?

If you can give yourself a satisfactory answer (one reason might be something like "to send a message to all other members of the party"), then consider ToohrVyk's advice.

Share this post


Link to post
Share on other sites
Well for this example there is no reason(even tho I think I will expand this a big as I can for pratice) but I do want to think as if this is a larger picture and I am doing what ToohrVyk said, I'm just pissed I did not think of it first on my own because that is not something new to me.

Share this post


Link to post
Share on other sites
Quote:
Original post by RyanZec
Well for this example there is no reason(even tho I think I will expand this a big as I can for pratice) but I do want to think as if this is a larger picture and I am doing what ToohrVyk said, I'm just pissed I did not think of it first on my own because that is not something new to me.


It's actually probably not that intuitive; it *is* a common, fundamental technique, but sometimes you have to see it quite a few times to really "get it".

As it happens, there are many such things in programming. [smile]

(Oh, and I should also link you here.)

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!