Whenever you have tightly coupled objects with circular dependencies, you have one of three cases (in an order of likelihood that I just pulled out of thin air, but sounds plausible):
You are missing an object, and the two objects are actually three objects.
The two objects are actually one object.
The business domain you are modeling is indeed circular, ...
The general relationship you have between your classes (0..1 User to 0..1 Thing) is a perfectly valid kind of relationship. It's less common, but valid in the right situation, which this seems to be.
However, you need to be very careful here. Your current setup creates a lot of room for contradiction. Part of this is because you store this information twice. ...
I would disagree with your observation that function composition is not common.
The name of that particular anti-pattern is procedural design.
In short, you are separating data from behavior, which arguably disqualifies this kind of design from being called object-oriented at all. More importantly it pushes the responsibility to handle these data things right to the caller, which is exactly your problem.
The way to fix this, is to hide ...
One way to ensure consistency of circular references such as this is to implement idempotent set/unset operations which call each other recursively unless the target condition is already satisfied. I don't speak C#, so please accept pseudocode:
public Thing curThing;
function setThing(Thing aThing)
if (this.curThing == ...
Whenever I modify one of them, I often need to call a corresponding function in the other class. If I am not careful about which functions call methods in the other class, I can end up with a stack over flow.
When reading this, my first thought was that User and Thing really should have been one class, but that then doesn't match with moving a Thing ...
What is validation?
Its a border guard between the unruly, disordered mess out there, and the nice well-behaved order in here.
There are a lot of borders.
There is the border between the keyboard on the input control.
The border between the input control and the ui code accessing its value.
The borders between various parts of the UI, as the data is passed ...