I frequently have a design problem in C# where I want to instantiate objects with their data complete, but they also need to reference their owner for ease-of-use. But then the pattern ends up being ugly, like:

UI.Add(new Button(UI, "Confirm"));

Where that first argument is redundant + error-prone.

You can delay the assignment, so the Add method assigns the owner (ex. itemBeingAdded.UI = this) but then the child doesn't have the owner until after its constructor.

You can create a pattern where child implementations just aren't supposed to do anything until an "OnAdded" is called, but that messes up readonly members and also makes it so they need to "cache" constructor arguments to be used later.

In C++ you could get around this with templates (pseudo code, can't remember syntax)

void Add<T>(constructor params) => children.Add(new T(this, constructor params));

and it wouldn't compile if you mess up the expected parameters. I kind of want that in C#.

I guess the "correct" thing to do is just not let instances hold a reference to their owner... but when I'm working on small projects it's often way, way simpler to be able to do that and I don't care about perfect data/control flow. I just want my objects created fully by the constructor!
@noelfb why not make the UI the ‘constructor’ by forcing use of a method it has ? Does C# allow constructors to be private ?
@noelfb why not have the child constructor add itself to ui as final step? I guess incomplete object causes issues?