3

私はしばらくの間、Objectクラスにパブリックなパラメーターなしのコンストラクターがある理由、または実際にマークされていない理由を特定しようと試みてきましたabstract。

Object;のパブリック コンストラクターを (明示的に) 呼び出す必要がある合理的な状況が見当たりません。派生型のコンストラクターにのみ関心があります。

暗黙的または明示的に呼び出すことができるデフォルト コンストラクターをObject他のすべてのコンストラクターに与えるために、 でデフォルト コンストラクターを提供する必要性を理解しています。Type確かに、このデフォルト コンストラクターは としてマークするだけprotectedで済みますね。

スレッド同期で「空のオブジェクト」を作成する人を見てきました。しかし、このシナリオでは「実際のオブジェクト」をロックする方が正しいのではないでしょうか?

同様に、Objectクラスによって公開される機能は派生型 (または静的に呼び出される) にのみ役立つため、抽象クラスではないのはなぜですか? これは、それ自体で意味のあるインスタンス化が可能であるという印象をプログラマーに与えるクラスを持つよりも優れた設計のように思えます。

答えは CLR の内部動作と関係があるのではないかと思いますObjectが、パブリック コンストラクターが必要な理由と、それをマークできない理由があるかどうかを知りたいabstractです。

4

2 に答える 2

2

確かに、スレッド同期に関係している可能性があります。http://msdn.microsoft.com/en-us/library/ms173179.aspxを参照してください。

マイクロソフトが使用しているという事実

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

彼ら自身の例では、彼らの意見では、同期のためだけに新しいオブジェクトを作成することは完全に正しいと言っています。

また、Java は同期の例でまったく同じことを許可しているため、Microsoft の開発者は、言語を動作させる標準的な方法のように見えるものに「追随」しただけかもしれません。

もちろん、CLR にも秘密の技術的な理由がある可能性もあります。

于 2012-11-01T05:27:59.730 に答える
0

Object を抽象化してはならない理由と、CLR の内部機能にデフォルトのコンストラクターを使用する理由の 1 つは、ボックス化とボックス化解除が発生したときです。

http://msdn.microsoft.com/en-us/library/yz2be5wk.aspx を確認してください

さらに、スレッド同期は「実際の」オブジェクトを使用する必要はありません。オブジェクトを使用する目的はロックを取得することであり (スレッドがロックを取得すると、他のすべての人はそのロックが解放されるまで待機する必要があります)、オブジェクトをロックすることではありません。オブジェクトそのもの。

議論のために、スレッドがその作業のために実際のオブジェクトに関心がない場合 (整数操作を行っている可能性があります)、デフォルトのコンストラクターで作成された空のオブジェクトを使用する必要があります。

于 2012-11-01T05:30:58.403 に答える