パラメーター付きのコンストラクターを作成すると、デフォルトのパラメーターレスコンストラクターがなくなる理由

C＃、C ++、およびJavaでは、パラメーターを受け取るコンストラクターを作成すると、パラメーターのないデフォルトのコンストラクターがなくなります。私は常にこの事実を受け入れてきましたが、今はなぜなのかと思い始めています。

この動作の理由は何ですか？「独自のコンストラクターを作成した場合、おそらくこの暗黙的なコンストラクターをぶら下げたくない」と言っているだけの「安全対策/推測」ですか？それとも、自分でコンストラクタを作成した後にコンパイラが追加できないようにする技術的な理由がありますか？

独自にコンストラクタを追加した場合、コンパイラがコンストラクタを追加できなかった理由はありません-コンパイラは必要に応じてほとんど何でもできます！ただし、最も意味のあるものを確認する必要があります。

• 私が定義されていない場合は任意の非静的クラスのコンストラクタを、私が最も可能性が高い、そのクラスをインスタンス化することができるようにしたいです。これを可能にするために、コンパイラーはパラメーターなしのコンストラクターを追加する必要があります。これは、インスタンス化を許可する以外には効果がありません。つまり、機能させるためだけにコードに空のコンストラクターを含める必要はありません。
• 独自のコンストラクター、特にパラメーター付きのコンストラクターを定義した場合、クラスの作成時に実行する必要がある独自のロジックを持っている可能性があります。この場合、コンパイラーが空のパラメーターのないコンストラクターを作成すると、誰かが私が書いたロジックをスキップできるようになり、コードがさまざまな方法で壊れる可能性があります。この場合にデフォルトの空のコンストラクターが必要な場合は、明示的に指定する必要があります。

したがって、どちらの場合でも、現在のコンパイラーの動作が、コードの意図を維持するという点で最も理にかなっていることがわかります。

言語がこのように設計されなければならない技術的な理由は確かにありません。

私が見ることができる4つのやや現実的なオプションがあります。

1. デフォルトのコンストラクタはありません
2. 現在のシナリオ
3. デフォルトでは常にデフォルトのコンストラクターを提供しますが、明示的に抑制することを許可します
4. 抑制されることを許可せずに常にデフォルトのコンストラクタを提供する

オプション1はいくぶん魅力的です。コーディングするほど、パラメーターのないコンストラクターが本当に必要になる頻度が減ります。いつの日か、実際にデフォルトのコンストラクタを使用する頻度を数える必要があります...

オプション2私は元気です。

オプション3は、残りの言語について、JavaとC＃の両方のフローに反します。Javaのデフォルトよりもプライベートなものを明示的に数えない限り、明示的に「削除」するものはありません。

オプション4は恐ろしいです-あなたは絶対に特定のパラメータで建設を強制することができるようにしたいです。どういうnew FileStream()意味ですか？

したがって、基本的に、デフォルトのコンストラクターを提供することはまったく理にかなっているという前提を受け入れた場合、独自のコンストラクターを提供したらすぐにそれを抑制することは非常に理にかなっていると思います。

編集。実際、最初の答えで私が言ったことは有効ですが、これが本当の理由です。

最初はCがありました。Cはオブジェクト指向ではありません（オブジェクト指向のアプローチをとることはできますが、それはあなたを助けたり、何かを強制したりしません）。

その後、C With Classesがあり、後にC ++に名前が変更されました。C ++はオブジェクト指向であるため、カプセル化を促進し、オブジェクトの不変を保証します。構築時、およびメソッドの最初と最後では、オブジェクトは有効な状態です。

これを行うための自然なことは、クラスが有効な状態で開始することを保証するために、常にコンストラクターを持たなければならないことを強制することです-コンストラクターがこれを保証するために何もする必要がない場合、空のコンストラクターがこの事実を文書化します。

しかし、C ++の目標は、可能な限りすべての有効なCプログラムが有効なC ++プログラムでもあるという点でCと互換性を持つことでした（もはやアクティブな目標ではなく、CからC ++への進化により、もはや保持されなくなりました。 ）。

この1つの影響は、 structとのclass。前者はCの方法（デフォルトではすべて公開）で行い、後者は適切なOOの方法で行います（デフォルトではすべて非公開です。開発者は公開したいものを積極的に公開します）。

もう1つは、C structにはコンストラクターがないためにコンストラクターを持つことができなかったCがC ++で有効であるためには、C ++の見方ではこれに意味がなければなりませんでした。したがって、コンストラクターがないと、不変条件を積極的に保証するというOOの慣行に反することになりますが、C ++はこれを、本体が空のように動作するデフォルトのパラメーターなしのコンストラクターがあることを意味すると解釈しました。

すべてのC structsが有効なC ++ structsになりました（つまり、C ++と同じでした）classesと、すべて-メンバーと継承-パブリック）。外部から、単一のパラメーターなしのコンストラクターがあるかのように扱われました。

ただし、コンストラクタをclassまたはに配置した場合はstruct、Cの方法ではなくC ++ / OOの方法で処理を行っていたため、デフォルトのコンストラクタは必要ありませんでした。

それは省略形として機能したため、互換性が他の方法では不可能だった場合でも人々はそれを使い続けました（Cにない他のC ++機能を使用していました）。

したがって、Javaが登場したとき（さまざまな方法でC ++に基づいて）、後でC＃（さまざまな方法でC ++とJavaに基づいて）が生まれたとき、彼らはこのアプローチを、プログラマーがすでに慣れている可能性があるため維持しました。

Stroustrupはこれについて彼のC ++プログラミング言語で書いています。C++ のデザインと進化における言語の「なぜ」にもっと焦点を当てています。

===元の回答===

これが起こらなかったとしましょう。

パラメーターなしのコンストラクターが必要でないとしましょう。コンストラクターがないとクラスを意味のある状態にすることができないためです。実際、これはstructC＃で発生する可能性のあるものです（ただし、C＃ですべてゼロとnullを意味のある方法で使用できないstruct場合は、非公開の最適化を使用することをお勧めします。の使用に関する設計上の欠陥struct）。

クラスがその不変条件を保護できるようにするには、特別なremoveDefaultConstructorキーワードが必要です。少なくとも、呼び出しコードがデフォルトを呼び出さないようにするために、パラメーターなしのプライベートコンストラクターを作成する必要があります。

これは言語をさらに複雑にします。それをしない方がいい。

全体として、コンストラクタを追加することでデフォルトを削除するのではなく、何もしないパラメータのないコンストラクタを追加するための構文上の砂糖として、コンストラクタがないことを考えるのが最善です。

オブジェクトの作成を制御するために自分で何もしない場合は、デフォルトのパラメーターなしのコンストラクターが追加されます。制御を取得するための単一のコンストラクターを作成すると、コンパイラーは「バックオフ」し、完全に制御できるようになります。

これがそうでない場合、オブジェクトをパラメーター付きのコンストラクターでのみ構築可能にする場合は、デフォルトのコンストラクターを無効にする明示的な方法が必要になります。

コンパイラの便利な機能です。パラメーター付きのコンストラクターを定義するが、パラメーターなしのコンストラクターは定義しない場合、パラメーターなしのコンストラクターを許可したくない可能性がはるかに高くなります。

これは、空のコンストラクターで初期化しても意味がない多くのオブジェクトの場合です。

それ以外の場合は、制限するクラスごとに、パラメーターのないプライベートコンストラクターを宣言する必要があります。

私の意見では、機能するためにパラメーターを必要とするクラスにパラメーターなしのコンストラクターを許可するのは良いスタイルではありません。

他のコンストラクタを定義していないのであれば、なぜデフォルトコンストラクタを宣言する必要がないのでしょうか。

非静的クラスにはコンストラクターが必須です。
したがって、コンストラクタを定義していない場合、生成されたデフォルトコンストラクタはC＃コンパイラの便利な機能にすぎません。また、コンストラクタがないとクラスは有効になりません。したがって、何もしないコンストラクタを暗黙的に生成しても問題はありません。周りに空のコンストラクタを置くよりも、明らかにきれいに見えます。

コンストラクタをすでに定義している場合、クラスは有効です。なぜコンパイラがデフォルトのコンストラクタが必要だと想定する必要があるのでしょうか。必要ない場合はどうしますか？属性を実装して、コンパイラーにデフォルトのコンストラクターを生成しないように指示しますか？それは良い考えではないと思います。

デフォルトのコンストラクタは、クラスにコンストラクタがない場合にのみ作成できます。コンパイラは、これをバックアップメカニズムとしてのみ提供するように記述されています。

パラメータ化されたコンストラクタがある場合、デフォルトのコンストラクタを使用してオブジェクトを作成したくない場合があります。コンパイラーがデフォルトのコンストラクターを提供した場合、引数なしでオブジェクトが作成されないようにするには、引数なしのコンストラクターを作成してそれをプライベートにする必要がありました。

また、デフォルトのコンストラクターを無効にすること、または「プライベート」にすることを忘れ、それによって潜在的な機能エラーをキャッチすることが困難になる可能性が高くなります。

また、オブジェクトをデフォルトの方法で作成するか、パラメータを渡して作成する場合は、引数なしのコンストラクタを明示的に定義する必要があります。これは厳密にチェックされており、コンパイラはそれ以外の場合は文句を言うため、ここで抜け穴はありません。

前提

この振る舞いは、クラスがデフォルトのパラメーターなしのパブリックコンストラクターを持つという決定の自然な拡張と見なすことができます。尋ねられた質問に基づいて、私たちはこの決定を前提とし、この場合は質問しないと仮定します。

デフォルトのコンストラクターを削除する方法

したがって、デフォルトのパラメーターなしのパブリックコンストラクターを削除する方法が必要です。この削除は、次の方法で実行できます。

1. 非公開のパラメーターなしコンストラクターを宣言する
2. パラメータを持つコンストラクタが宣言されたときに、パラメータのないコンストラクタを自動的に削除します
3. パラメーターなしのコンストラクターを削除するようコンパイラーに指示するいくつかのキーワード/属性（簡単に除外できるほど厄介です）

最適なソリューションの選択

次に、自分自身に問いかけます。パラメータのないコンストラクタがない場合、何に置き換える必要がありますか？そして、どのような種類のシナリオで、デフォルトのパラメーターなしのパブリックコンストラクターを削除しますか？

物事は所定の位置に収まり始めます。まず、パラメータ付きのコンストラクタ、または非パブリックコンストラクタに置き換える必要があります。次に、パラメーターなしのコンストラクターが不要なシナリオは次のとおりです。

1. クラスをインスタンス化したくない、またはコンストラクターの可視性を制御したい：非パブリックコンストラクターを宣言する
2. 構築時にパラメーターを強制的に提供したい：パラメーターを使用してコンストラクターを宣言する

結論

C＃、C ++、およびJavaがデフォルトのパラメータなしのパブリックコンストラクタを削除できるようにする2つの方法があります。

これはコンパイラによって処理されると思います。で.netアセンブリを開くILDASMと、コード内にない場合でも、デフォルトのコンストラクタが表示されます。パラメータ化されたコンストラクタを定義する場合、デフォルトのコンストラクタは表示されません。

実際、クラス（静的でない）を定義すると、コンパイラーはこの機能を提供し、インスタンスを作成するだけだと考えます。また、特定の操作を実行したい場合は、必ず独自のコンストラクターを使用します。

これは、コンストラクタを定義しない場合、コンパイラは引数を取らないコンストラクタを自動的に生成するためです。コンストラクターにもっと何かが必要な場合は、オーバーライドします。これは関数のオーバーロードではありません。そのため、コンパイラが現在見る唯一のコンストラクタは、引数を取るコンストラクタです。この問題に対処するために、コンストラクターが値なしで渡された場合にデフォルト値を渡すことができます。

クラスにはコンストラクタが必要です。これは必須の要件です。

• 作成しない場合は、パラメータなしのコンストラクタが自動的に提供されます。
• パラメータなしのコンストラクタが必要ない場合は、独自のコンストラクタを作成する必要があります。
• パラメーターなしのコンストラクターとパラメーターベースのコンストラクターの両方が必要な場合は、手動で追加できます。

私は別の質問であなたに答えますが、なぜデフォルトのパラメータレスコンストラクタが常に必要なのですか？これが望ましくない場合があるため、開発者は必要に応じて追加または削除するコントロールを持っています。