How to best deal with circular dependencies?
Currently I'm working on a little larger project ( large for me, for some, small).
I've came across circular dependencies twice now. First time It took me 5 hours to fix it.
Now ( the second time), I'm struggling again to solve the problem but without success ( forward class declaration does not solve the problem).
I've started drawing diagrams of how classes are included (#include) between each other on a piece of paper ( I discovered that I still can hand write :) ). But now, after countless of failed attempts, I started to run out of paper.
So my question is: How to best deal with this problem? What are the methods?
from what you have described it seems to me that your design or even your SW architecture failed.
This task is very time consuming. It is almost like solving puzzles like Sudoku, Kakuro an all the other ones.
Without any further info it is hard to guess for a right solution.
Try to find a person near you with whom you can discuss that problem or you can provide us a screenshot of your calls diagram which shows the circular dependency.
The final conclusion is that there is no easy solution for every circular dependency problem.
I hope you will find a solution.
Image of how files are called for my problem is "here":http://i50.tinypic.com/mjv1q0.jpg .
Nodes that arrows point to are those which get included.
Order of those is always from left to right.
Yellow lines are the problematic one. It's hard to miss those gigantic loops.
But I still need those connections (includes) somehow down there or a code redesign as you already mentioned.
Any ideas are more than welcome.
Few things will be changed in the future (docks moved to main window).
Also I only visualized calls for problematic part of a program.
In Bruce Eckel: Thinking in C++ book there is a idea for this problem.
This book is free, download and unzip it, and search this string in it: DEPENDENCY1_H
I hope, this little tricky sample program can help you.
Sorry I was not able to open the link.
Is it really working?
The link is OK for me:
Ok it seems to me that the link was not working from my office.
Now I can seen it.
1.) Why do you need an association between Project and ItemDialog
Is ItemDialog inherited from QDialog? I guess that you like to access or to passe something to
the class Project.
2.) Why do you need an association between Project and GraphicsItem
GraphisItem should be managed either by an extra manager or by the Scene.
I would guess that you need to implement a structural pattern in your design.
Check out this link. It will help you to understand:
First off all, I made a mistake while making a diagram. Those yellow connections go one level lower (to Program). -I'll upload another image- (Uploaded "here":http://i50.tinypic.com/mjv1q0.jpg).
1.) Association between Program (Project on image) and ItemDialog ( yes it inherits QDialog), is needed because when it's open, completers are added to all QLineEdit classes. Data is generated in VariableManager class which Program inherits.
2.) It was only helper class to "relay" Program ( Project on image) pointer to ItemDialog class when constructing it. I Can and will do a workaround for this.
And thanks a lot for the link. I was searching for something like that a few times already, but found nothing useful.
VariableManger can be realized with Factory Pattern.
For your other problem I think if you can't solve the circular dependency a BridgePattern can solve your problem.
Checkout this link. It is superb resource:
Variable manager in this case I believe is realized correctly.
It's not like it's not exactly the first thing that comes across your mind when you hear "variable manager". It's used to manage variables (history, types, values and views) retrieved from lua program.
For my second problem, bridge probably will be a solution. I don't know how yet, but I'll first finish with given website about structural design, if I'll find any other more appropriate solution.