Re: mutual dependency
Victor Bazarov wrote:
Stuart Golodetz wrote:
Victor Bazarov wrote:
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 :)
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.
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
> 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.
V