adam.mad...@gmail.com a =E9crit :

On Dec 6, 10:01 pm, Karthik V <karthikveeram...@gmail.com> wrote:

I've been facing this situation often:

class NewFeature
{
TheClass *theClass;
NewFeature(TheClass *t) { theClass =3D t; }
void act() { // call methods on theClass }

}

class TheClass
{
NewFeature *feature; // More commonly, a list of NewFeature objects
AddFeature(NewFeature *f) { feature =3D f; // or append f to a list o=

NewFeature objects }

}

In the above case, TheClass class contains pointers to NewFeature
objects, and each NewFeature object contains a pointer to the same
TheClass instance. This does seem to work most of the time but I'm not
comfortable with the idea of this circular reference.

From a pure design point of view, you are right that it smells. But
sometimes, it is the more natural way of doing rather than go through
complex construction.

This often happen, as in your case a class owning a feature, when an
object has to keep a pointer on the object that owns it. The only
difficulty is lifetime issues: making the difference when a object is
destroyed by the object that own its or by other mean; there are many
strategy to adresse that.

Is there a standard design pattern to overcome this? The closest I saw
was visitor pattern.

Visitor tends to increase coupling between classes. I am pretty sure it
is not what you want.

The right solution greatly depends on what you want to achieve and the
environment you work in.
A generic solution (not the best for you) is defining an interface class
that is taken in parameter by a NewFeature. TheClass would inherit from
this interface and pass itself in parameter to the NewFeature.

If I use that here, I'd do something like

class NewFeature
{
TheClass *theClass;
void accept(TheClass *t) { theClass =3D t; }
void act() { // call methods on theClass }

}

class TheClass
{
AddFeature(NewFeature *f) { f->accept(this); f->act(); }

}

But in this case, I'm losing the ability to keep track of the
NewFeature objects I have. Especially, if NewFeature.act() runs some
thread that calls TheClass methods later, I want TheClass to be able
to start / stop the thread when I want; so maintaining a list of those
pointers will be useful. If I do, I end up having my earlier code.

You could also lookup "observer pattern" and signal/slot idiom. You
could also split your classes; it seems to me that TheClass has a lot of
responsibilities :start/stop thread, provides functions called into the
thread.
I can't help you there, it is your design.

There is nothing wrong with using your method. You have just keeping a
pointer to the object and not the actual object thus you have no
circular reference. All the pointer is in the most general sense is an
integer. Using the actual object would be bad though as this would be
like having a nested class structure and lead to looping in
compilation.

The OP problem is not from a compilation point of view but rather a
design issue.

Michael

adam.mad...@gmail.com a =E9crit :

On Dec 6, 10:01 pm, Karthik V <karthikveeram...@gmail.com> wrote:

I've been facing this situation often:
class NewFeature
{
TheClass *theClass;
NewFeature(TheClass *t) { theClass =3D t; }
void act() { // call methods on theClass }
}
class TheClass
{
NewFeature *feature; // More commonly, a list of NewFeature objects
AddFeature(NewFeature *f) { feature =3D f; // or append f to a list o=

NewFeature objects }
}
In the above case, TheClass class contains pointers to NewFeature
objects, and each NewFeature object contains a pointer to the same
TheClass instance. This does seem to work most of the time but I'm not
comfortable with the idea of this circular reference.

From a pure design point of view, you are right that it smells. But
sometimes, it is the more natural way of doing rather than go through
complex construction.

This often happen, as in your case a class owning a feature,
when an object has to keep a pointer on the object that owns
it. The only difficulty is lifetime issues: making the
difference when a object is destroyed by the object that own
its or by other mean; there are many strategy to adresse that.

Is there a standard design pattern to overcome this? The
closest I saw was visitor pattern.

Visitor tends to increase coupling between classes. I am
pretty sure it is not what you want.

If I use that here, I'd do something like

class NewFeature
{
TheClass *theClass;
void accept(TheClass *t) { theClass =3D t; }
void act() { // call methods on theClass }
}
class TheClass
{
AddFeature(NewFeature *f) { f->accept(this); f->act(); }
}
But in this case, I'm losing the ability to keep track of
the NewFeature objects I have.

Especially, if NewFeature.act() runs some thread that calls
TheClass methods later, I want TheClass to be able to start
/ stop the thread when I want; so maintaining a list of
those pointers will be useful. If I do, I end up having my
earlier code.

You could also lookup "observer pattern" and signal/slot
idiom. You could also split your classes; it seems to me that
TheClass has a lot of responsibilities :start/stop thread,
provides functions called into the thread. I can't help you
there, it is your design.