Каковы преимущества класса Object, имеющего открытый конструктор без параметров?

Question

Я некоторое время пытался определить, почему Object класс имеет открытый конструктор без параметров или, действительно, почему он не помечен abstract,

Я не вижу разумных обстоятельств, когда необходимо (явно) вызвать открытый конструктор Object; нас интересуют только конструкторы производных типов.

Я понимаю необходимость предоставить конструктор по умолчанию в Object, чтобы дать друг другу Type конструктор по умолчанию, который он может вызывать, неявно или явно. Конечно, этот конструктор по умолчанию должен быть помечен только как protectedне так ли?

Я видел, как люди создают "пустые объекты" в синхронизации потоков; но не правильнее ли заблокировать "реальный объект" в этом сценарии?

Аналогично, поскольку функциональность, предоставляемая Object Класс полезен только для производных типов (или называется статически), почему он не является абстрактным классом? Это может показаться лучшим дизайном, чем иметь класс, который создает у программистов впечатление, что его можно осмысленно создать самостоятельно.

Я подозреваю, что ответ может иметь отношение к внутренней работе CLR, но я хотел бы знать, почему это необходимо для Object иметь открытый конструктор, и если есть какая-либо причина, почему он не может быть помечен abstract,

Answer 1

Это действительно, вероятно, связано с синхронизацией потоков. См. http://msdn.microsoft.com/en-us/library/ms173179.aspx

Тот факт, что Microsoft использует

private System.Object lockThis = new System.Object();

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

Кроме того, Java допускает то же самое в своих примерах синхронизации, поэтому разработчики Microsoft могли просто "последовать их примеру" с тем, что казалось стандартным способом поведения языка.

Конечно, также возможно, что в CLR есть какая-то секретная техническая причина.

Answer 2

Одна причина, по которой я могу подумать, почему Object не следует делать абстрактным, а конструктор по умолчанию используется для внутренней функциональности CLR, - это когда происходит упаковка и распаковка.

Проверьте http://msdn.microsoft.com/en-us/library/yz2be5wk.aspx

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

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