mutual dependency
thomas
class A{
public:
A(){}
void f(){
B *b = new B();
}
};
class B{
public:
B(){}
void f(){
A *a = new A();
}
};
---------------code------------
for the above sample code, there's compile error.
if I put a declaration "class B;" at the begining, it says that no
default constructor.
how to declare a default constructor to avoid the compile error?
Saeed Amrollahi
Hi Thomas
Put the definition of A::f() after the the defintion of B:
class A{
public:
A(){}
void f();
};
class B{
public:
B(){}
void f() {
A *a = new A();
}
};
void A::f()
{
B *b = new class B();
}
it compiles and works.
FYI, such mutual dependency isn't good sign of object-oriented design.
Regards,
-- Saeed Amrollahi
Victor Bazarov
> On Oct 30, 11:47 am, thomas <freshtho...@gmail.com> wrote:
>> -------------code------------
>> class A{
>> public:
>> A(){}
>> void f(){
>> B *b = new B();
>> }
>>
>> };
>>
>> class B{
>> public:
>> B(){}
>> void f(){
>> A *a = new A();
>> }};
>>
>> ---------------code------------
>> for the above sample code, there's compile error.
>> if I put a declaration "class B;" at the begining, it says that no
>> default constructor.
>> how to declare a default constructor to avoid the compile error?
>
>
> FYI, such mutual dependency isn't good sign of object-oriented design.
Really? Why is that?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Saeed Amrollahi
>
> - Show quoted text -
Hi Victor
I just mean, with a good design, we can avoid such mutual
dependencies.
I face with the following code patterns a lot of times:
class A {
B* pB;
};
class B {
A* pA;
};
with a review on class design I can avoid such "mutual" dependencies.
Regards,
-- Saeed Amrollahi
Stuart Golodetz
> Saeed Amrollahi wrote:
>> On Oct 30, 11:47 am, thomas <freshtho...@gmail.com> wrote:
>>> -------------code------------
>>> class A{
>>> public:
>>> A(){}
>>> void f(){
>>> B *b = new B();
>>> }
>>>
>>> };
>>>
>>> class B{
>>> public:
>>> B(){}
>>> void f(){
>>> A *a = new A();
>>> }};
>>>
>>> ---------------code------------
>>> for the above sample code, there's compile error.
>>> if I put a declaration "class B;" at the begining, it says that no
>>> default constructor.
>>> how to declare a default constructor to avoid the compile error?
>>
>> [..]
>>
>> FYI, such mutual dependency isn't good sign of object-oriented design.
>
> Really? Why is that?
>
> V
I suspect you're playing devil's advocate here Victor :) I'm going to
direct the OP to Lakos's Large-Scale C++ Software Design, which had
quite a good discussion of issues to do with cyclic dependencies. (I
know it's possibly a bit dated in some ways now, but I remember it being
fairly decent.)
Stu
Victor Bazarov
Saeed in his reply quoted a different kind of dependency than the OP
had, and that's one of my points - there are different types of
dependency, and this particular one usually isn't especially bad, or an
indication of a bad design. For example, updating data usually follows
with updating the view associated with data, and vice versa, user
interaction with the view can cause an update in the data... Is that a
flaw in the design? Mmm... No.
> I'm going to
> direct the OP to Lakos's Large-Scale C++ Software Design, which had
> quite a good discussion of issues to do with cyclic dependencies. (I
> know it's possibly a bit dated in some ways now, but I remember it being
> fairly decent.)
It's a decent book once you learn to skip irrelevant or obsolete parts.
Victor Bazarov
Do explain. Please.
> I face with the following code patterns a lot of times:
> class A {
> B* pB;
> };
>
> class B {
> A* pA;
> };
>
> with a review on class design I can avoid such "mutual" dependencies.
But that's not what the OP has. Look again.
Stuart Golodetz
Agreed. That's just the Model-View-Controller pattern by the sound of
it, which definitely isn't a design flaw. On the other hand, it's
certainly possible to implement MVC in a flawed way - e.g. where the
model has direct physical dependencies on the views which are listening
to it (rather than letting them know it's changed indirectly by using a
listener approach). Two-way communication between things like models and
views can be necessary - the trick (such as it is) is in getting the
implementation right and avoiding the undesirable mutual physical
dependency between the classes.
Regards,
Stu