Cyclic dependencies

[laulaub]

Hello,

I am currently in the process of creating a small game using SDL. I have been working on a state manager that manages switching between for example the introduction and the actual game.

To realize this I have a class StateManager and a class State. The introduction and the actual game state derive from this state (IntroState, GameState). The StateManager has a reference to a State so it knows what state to draw and handle input for. The state also has a reference to the StateManager so it can switch to a different state. Imagine the IntroState is active and the player presses the "Escape" key. The IntroState can then tell the StateManager to switch to the GameState.

This obviously creates a cyclic dependency. StateManager depends on State and State depends on StateManager. I have read several articles on the subject and nearly all are saying that cyclic dependencies are very bad design. I was wondering if it is really bad design in my particular case. Re-usability is not really an issue here because if the classes are ever re-used, they are re-used together.

I could of course easily break the dependency but then I would have a class of which the only purpose is to break the dependency and this sounds like design to me as well.

What is your take on this issue? Is the cyclic dependency OK in this particular situation or would it be better to break it?

Thanks!

[helios]

class StateManager;

class State{ /*...*/ };

class StateManager{ /*...*/ };

Any member function of State that makes use of the pointer to a StateManager will have to be defined after the proper definition of StateManager.

[laulaub]

Hello,

Thanks for your swift reply.

The problems was however not so much as how I would implement it but more if the cyclic dependency is considered bad design in the case I described in the original post.

Thanks!

[helios]

Oh, sorry, I didn't see that part.

I have read several articles on the subject and nearly all are saying that cyclic dependencies are very bad design.

I can't see why that would be. Could you post some links?

[laulaub]

Sure, here goes:

(...) However, in software design circular dependencies between larger software modules are considered an anti-pattern because of their negative effects.

http://en.wikipedia.org/wiki/Circular_dependency

(...)But cyclic dependencies are especially bad. (...) It's a maintenance and testing issue, since you can't do anything to either class without possibly affecting the other.

http://blog.kirkk.com/index.php?itemid=30

http://wiki.architecturerules.org/index.php/CyclicDependencies

[helios]

All those are talking about cyclic dependencies between modules, which is not the case here, AFAICT. What you have here is a tree structure where the children point to the parent. This is similar to a directory structure:

class directory;

class generic_file{
    directory *parent;
};

class directory:generic_file{
    generic_file *children;
};

class file:generic_file{
};

In this case, the pointer to the parent doesn't absolutely need to be there, but the alternative would be to traverse the tree structure to find the path to a file based on its pointer.
Doing that would be far worse than eliminating the dependency.
Cyclic dependency should indeed be avoided, but between mostly unrelated modules. In this and your cases, the classes are so tightly bound that they're part of a single module.