I have been trying for some time to determine why the Object class has a public, parameterless constructor or, indeed, why it is not marked abstract.
I cannot see a reasonable circumstance where it would be necessary to (explicitly) call the public constructor of Object; we are only ever interested in the constructors of derived types.
I understand the need to provide a default constructor in Object, to give every other Type a default constructor that it can call, either implicitly or explicitly. Surely, though, this default constructor would only need to be marked as protected, wouldn't it?
I've seen people construct 'empty objects' in thread synchronisation; but isn't it more correct to lock a 'real object' in this scenario?
Likewise, since the functionality exposed by the Object class is only useful to derived types (or called statically), why isn't it an abstract class? This would seem like a better design than to have a class which gives programmers the impression that it can be meaningfully instantiated on its own.
I suspect the answer may have something to do with the inner workings of the CLR, but I would like to know why it's necessary for Object to have a public constructor, and if there is any reason why it couldn't be marked abstract.
It is indeed probably to do with thread synchronization. See http://msdn.microsoft.com/en-us/library/ms173179.aspx
The fact that Microsoft uses
private System.Object lockThis = new System.Object();
In their own example tells me that in their opinion, it is perfectly correct to make a new object solely for the purpose of synchronization.
Also, Java allows the exact same thing in their synchronization examples, so Microsoft's developers might have just "followed suit" with what seemed like the standard way to have the language behave.
It is of course also possible that there is some secret technical reason in the CLR as well.