K
KaiWen
Many forward reference in the code. Is it a ugly design?
L
Lynn McGuire
If it is then so is mine. I've got about 30
classes forward referenced. Can't get a clean
compile without doing that. This is a user
interface program with about 700 classes.
Lynn
K
KaiWen
I think a class reference many classes, it mean it know too much.
A
Alf P. Steinbach
A large number of forward references need not be a sign of bad design.
For example, for a sufficiently large system build time can be an
important criterion. Trading some idealism for shorter build time can
make sense.
However, a large number of circular references indicate that things
could be simplified a lot. Whether it's worth the time to do it, that's
another question.
So, I think, the OP's question has too little information to say
anything (we don't know the reason for the forward references), and your
reply has too little information (we don't know the cost of working out
the circular references, or where they came from).
But as a general rule, it's a good idea to try to avoid circular type
dependencies.
Circular dependencies make things complicated both for physical
packaging of the code, and for understanding the constraints on data
structures etc., and for automating things via smart-pointers.
Cheers,
- Alf
J
Jorgen Grahn
It's called a "forward declaration", by the way.
But the number of forward declarations is not a good measure of that.
Most of my forward declarations aren't there to break circular
dependencies -- they are there to cut down on #including. I can reduce
the number of forward declarations by including the headers with the
real declarations, but that would make the code /worse/.
/Jorgen
But the number of forward declarations is not a good measure of that.
Most of my forward declarations aren't there to break circular
dependencies -- they are there to cut down on #including. I can reduce
the number of forward declarations by including the headers with the
real declarations, but that would make the code /worse/.
/Jorgen
K
KaiWen
Sorry, my english is not good. I'm a new hand.
I use forward references to break circular dependencies.
It's just a smell when I wrote my class. I felt it's not good when
there are too many forward references.
As you said, I need a general rule. Is there any way (or pattern, if
there is, too happy) to avoid this.
K
KaiWen
Thanks.
K
KaiWen
Sorry, It's "forward declaration", I fell so awkward.
N
Nobody
Too many circular dependencies tends to indicate a lack of modularity,
every component needing to know the details of every other component.
One way to eliminate such dependencies is by splitting a class into an
interface (with no member variables and only pure virtual methods) and an
implementation (which derives from the interface).
E.g. rather than A having a reference to B and B having a reference to A,
A has a reference to X, B is derived from X, B has a reference to A. These
can be defined in the order X, A, B, with no circularity.
K
KaiWen
Hum, a good idea.
I found another way to do it.
eg:
If A have a reference to B, and B have a reference to A.
In A::do_something() will call
B::do_something(), then let A have a function object, which is a
wrapper
of B::do_something(). (The function could be boost::function or
something other).
Advantage:
Firstly, the function object in A could reference to
B::do_some_thing() or a
globe function or some_other_object::do_something(), and can be
replaced at
runtime.
Secondly, if A only call B::do_something(), A has a reference of B
(know all
of the interface of B) is unnecessary, and a forward declaration is
unnecessary too.
P
Paul N
Is it possible to use "layers" where each class only deals with
classes in the next layer down? Or more generally, to decide for each
class how "basic" or "high-level" it is, and only have it call classes
that are more fundamental?