Как спроектировать класс, чтобы круговые зависимости не вызывали производные члены перед созданием?

Лично я не люблю циклические ссылки. Но если вы решите их оставить, можно добавить немного лени:

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. */ }
}  

Ленивость здесь позволяет гарантировать, что реализация IKernel будет полностью инициализирована, когда будет запрашиваться экземпляр FileManager.

Для меня наличие циклических зависимостей между такими объектами плохо пахнет.

Я думаю, вы должны решить, какой объект является основным, а какой является предметом для агрегации или даже композиции. Затем создайте вторичный объект внутри основного или, альтернативно, внедрите его как зависимость от основного объекта. Затем позвольте основному объекту зарегистрировать свои методы обратного вызова во вторичном объекте, который будет вызывать их всякий раз, когда ему нужно будет связаться с «внешним миром».

Если вы решите, что типом отношения является агрегация, то, как только основной объект будет уничтожен, он отменит регистрацию всех обратных вызовов.

А если идти с композицией, то просто уничтожайте второстепенный объект, когда разрушается основной.

Вот пример того, что я имею в виду:

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 );
    }
}

Если вам нужно сохранить пары объектов со ссылками друг на друга, вы должны предоставить утилиту для их правильного построения. Используйте шаблон Factory и уменьшите сложность построения, спрятав конструкцию и сборку за методами шаблона Factory.

В Java поместите конструктор в пакет и сделайте конструкторы внутреннего компонента и методы начальной установки присваивания "пакетными частными"

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;
}

Аналогичная идея может быть реализована в C++ с продуманным использованием private и friend.

Хотя декларативной поддержки такой конструкции не существует, я бы предложил определить (через комментарии) категорию конструкторов и параметров, защищенных от утечек, со следующими ограничениями:

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.

Если кто-то соблюдает такие ограничения, должно быть возможно, чтобы конструкторы с защитой от утечек создавали объекты, которые взаимно ссылаются друг на друга, таким образом, который может быть статически продемонстрирован, никогда не разыменовываются какие-либо частично сконструированные объекты вне их конструкторов (конструктор Foo может передать создаваемый объект конструктору Bar, но если этот конструктор не разыменовывает переданный объект, не предоставляет его какому-либо коду, который мог бы это сделать, и не сохраняет его где-либо вне себя, единственный способ разыменовать его — это быть путем разыменования только что созданного экземпляра Bar; если конструктор Foo этого не сделает, он не будет разыменован до тех пор, пока не вернется конструктор Foo).