Sign in to follow this  

circular dependencies problem

This topic is 3859 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
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
ToohrVyk idea does not work the way I want it to. I want both party objects and player object to be able to add/drop player. The problem is I can add from the player but not from party. The reason I can't add from party is becuase the character class(which is what the party class uses to store it players) but in order to store the players current party I need access to the player class inside the party class.

Share this post


Link to post
Share on other sites

This topic is 3859 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this