8
コンストラクターではなく、JavaとC#の静的mainメソッドが必要な理由
Applicationクラスのインスタンス(エントリポイントを含む)でアプリケーションインスタンスを表すのではなく、(特に)JavaとC#が静的メソッドをエントリポイントとして持つことにした理由について、プライマリソースまたはセカンダリソースからの明確な回答を探しています。適切なコンストラクタであること)。 私の以前の研究の背景と詳細 これは以前に尋ねられました。残念ながら、既存の回答は単に質問を懇願しているだけです。特に、次の答えは私を満足させるものではありません。 コンストラクターがオーバーロードされると、あいまいさが生じます。–実際、C#(およびCとC ++)では異なる署名を使用できるMainため、同じ潜在的なあいまいさが存在し、対処されます。 staticこの方法は、その初期化の順序は明らかである前に、何のオブジェクトをインスタンス化することはできないことを意味します。–これは事実上間違っています。一部のオブジェクトは前にインスタンス化されます(静的コンストラクターなど)。 したがって、親オブジェクトをインスタンス化することなく、ランタイムによって呼び出すことができます。–これはまったく答えではありません。 なぜこれが有効で興味深い質問であると思うのかをさらに正当化するために: 多くのフレームワークは、クラスを使用してアプリケーションを表し、コンストラクターをエントリポイントとして使用します。たとえば、VB.NETアプリケーションフレームワークは、専用のメインダイアログ(およびそのコンストラクター)をエントリポイント1として使用します。 JavaもC#も技術的にmainメソッドを必要としません。まあ、C#をコンパイルするには1つが必要ですが、Javaでもそれは必要ありません。また、どちらの場合も実行には必要ありません。したがって、これは技術的な制限ではないようです。そして、最初の段落で述べたように、単なる慣習としては、JavaとC#の一般的な設計原則に不自然に合わないようです。 明確に言うと、静的メソッドを使用することには特別な欠点はありません。それは明らかに奇妙です。そのため、技術的な根拠があるのではないかと思いました。main 私は単なる推測ではなく、一次または二次情報源からの決定的な答えに興味があります。 1ただし、Startupこれをインターセプトする可能性のあるコールバック()があります。
54
java
c#
history
entry-point