circular dependencies problem
Author
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?
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.
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.
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.
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.
Author
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.
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.
Author
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.
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.)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement