How to design a class to prevent circular dependencies from calling derived members before construction?

Question

(I tagged this as both C# and Java, since it's the same question in both languages.)

Say I have these classes

interface IKernel
{
    // Useful members, e.g. AvailableMemory, TotalMemory, etc.
}

class Kernel : IKernel
{
    private /*readonly*/ FileManager fileManager;  // Every kernel has 1 file manager
    public Kernel() { this.fileManager = new FileManager(this); /* etc. */ }

    // implements the interface; members are overridable
}

class FileManager
{
    private /*readonly*/ IKernel kernel;  // Every file manager belongs to 1 kernel
    public FileManager(IKernel kernel) { this.kernel = kernel; /* etc. */ }
}

The problem with this design is that as soon as FileManager tries to do anything inside its constructor with kernel (which it might reasonably need to), it will be calling a virtual method on a potential subclass instance whose constructor is not yet called.

This problem doesn't occur in languages where you can define true constructors (rather than initializers, like C#/Java), since then the subclasses don't even exist before their constructors are called... but here, this problem happens.

So what is the best/proper design/practice, to ensure this doesn't happen?

Edit:

I'm not necessarily saying I need circular references, but the fact is that both Kernel and FileManager depend on each other. If you have a suggestion on how to alleviate this problem without using circular references, then that's great too!

Answer 1

To me, having circular dependencies between this kind of objects smells badly.

I think you should decide which object is the main one, and which one is the subject for aggregation, or even composition. Then construct the secondary object inside of the main one, or alternatively, inject it as a dependency of the main object. Then let the main object register its callback methods in the secondary object, which will call them whenever it needs to communicate with the "outer world".

If you decide that the relation type is aggregation, then once the main object is to be destroyed, it will unregister all the callbacks.

And if you go with composition, then just destroy the secondary object when the main one is being destroyed.

Here's an example of what I mean:

class Program
{
    static void Main( )
    {
        FileManager fm = new FileManager( );
        Kernel k = new Kernel( fm );
        fm.DoSomething( 10 );
    }
}

class Kernel
{
    private readonly FileManager fileManager;
    public Kernel( FileManager fileManager )
    {
        this.fileManager = fileManager;
        this.fileManager.OnDoSomething += OnFileManagerDidSomething;
    }

    ~Kernel()
    {
        this.fileManager.OnDoSomething -= OnFileManagerDidSomething;
    }

    protected virtual void OnFileManagerDidSomething( int i )
    {
        Console.WriteLine( i );
    }
}

class FileManager
{
    public event Action<int> OnDoSomething;

    public void DoSomething( int i )
    {
        // ...

        OnDoSomething.Invoke( i );
    }
}

Answer 2

Personally, I don't like circular references. But if you decide to leave them, you may add some laziness:

interface IKernel
{
    // Useful members, e.g. AvailableMemory, TotalMemory, etc.
}

class Kernel : IKernel
{
    private readonly Lazy<FileManager> fileManager;  // Every kernel has 1 file manager
    public Kernel() { this.fileManager = new Lazy<FileManager>(() => new FileManager(this)); /* etc. */ }

    // implements the interface; members are overridable
}

class FileManager
{
    private /*readonly*/ IKernel kernel;  // Every file manager belongs to 1 kernel
    public FileManager(IKernel kernel) { this.kernel = kernel; /* etc. */ }
}  

Laziness here lets ensure, that IKernel implementation will be initialized completely, when FileManager instance will be queried.

Answer 3

If you need to keep pairs of objects, with references to each other, you should provide a utility to build them correctly. Use the Factory pattern, and reduce the complexity of construction by hiding the construction and assembly behind the Factory pattern methods.

In Java, put the constructor in the package, and make the internal component's constructors and initial assignment set up methods "package private"

public Kernel newKernel() {
  Kernel kernel = new Kernel();
  Filesystem filesystem = new Filesystem();
  kernel.setFilesystem(filesystem);
  filesystem.setKernel(kernel);
  return kernel;
}

public Filesystem newFilesystem() {
  Kernel kernel = new Kernel();
  Filesystem filesystem = new Filesystem();
  kernel.setFilesystem(filesystem);
  filesystem.setKernel(kernel);
  return filesystem;
}

A similar idea can be had in C++ with thoughtful use of private and friend.

Answer 4

Although there isn't any declarative support for enforcing such a construct, I would suggest that one defines (via comments) a category of leak-safe constructors and parameters subject to the following constraints:

1. A leak-safe constructor may use leak-safe parameters only to call call nested leak-safe constructors (where the parameters must also be passed as leak-safe), or store them in its own fields.
2. A leak-safe constructor may not dereference any leak-safe parameters, nor any field that is loaded from a leak-safe parameter.
3. A leak-safe constructor may not pass the object under construction anywhere except as a leak-safe parameter to a nested leak-safe constructor.
4. An object constructed by calling passing a leak-safe parameter or the object under construction to a leak-safe constructor will be subject to all of the constraints of a leak-safe parameter.

If one abides by such constraints, it should be possible to have leak-safe constructors produce objects that mutually refer to each other, in a manner which can be statically demonstrated never to any partially-constructed objects be dereferenced outside their constructors (the constructor of Foo may pass the object under construction to the constructor of Bar, but if that constructor neither dereferences the passed-in object nor exposes it to any code that might do so, nor persists it anywhere outside itself, the only way it could get dereferenced would be by dereferencing the newly-created instance of Bar; if Foo's constructor doesn't do that, it won' get dereferenced until Foo's constructor returns).