Is it bad practice to have a class that requires a reference to the instantiating object?

Question

I saw this in someone's code and thought wow, that's an elegant way to solve this particular problem, but it probably violates good OO principles in an epic way.

In the constructor for a set of classes that are all derived from a common base class, he requires a reference to the instancing class to be passed. For example,
Foo Foo_i = new(this);

Then later on Foo would call methods in the instancing class to get information about itself and the other objects contained by the instancing class.

On the one hand, this simplifies a TON of code that models a 5-layer tree structure in hardware (agents plugged into ports on multiple switches, etc). On the other hand, these objects are pretty tightly coupled to each other in a way that seems pretty wrong, but I don't know enough about OOA&D to put my finger on it.

So, is this okay? Or is this the OO equivalent to a goto statement?

Answer 1

You shoud try to avoid mutual references (especially when implemeting containment) but oftentimes they are impossible to avoid. I.e. parent child relationship - children often need to know the parent and notify it if some events happen. If you really need to do that - opt for interfaces (or abstract classes in case of C++). So you instancing class should implement some interface, and the instanciated class should know it only as interface - this will sigificantly reduce coupling. In some respect this approach is similar to nested listener class as it exposes only part of the class, but it is easier to maintain. Here is little C# example:

interface IParent
{
    //some methods here
}

class Child
{
    // child will know parent (instancing class) as interface only
    private readonly IParent parent_;
    public Child(IParent parent)
    {
        parent_ = parent;
    }
}

class Parent : IParent
{
    // IParent implementation and other methods here
}