これは.NETですが、単純化するために、プリンシパルはすべてのOOP言語に適用する必要があると確信しています。例として.NETを取り上げます。
R#は通常、作成者のコンストラクターであり、入力変数をプライベートフィールドに渡します。これは、私にとってはプロパティに渡す傾向があります。
その違いとそのためのベストプラクティスについての意見はありますか?
プロパティの使用は、それらが仮想/オーバーライドされていない限り問題ありません。プロパティは本質的にメソッドであり、適切な型がまだ構築されていない可能性があるため、コンストラクター内から仮想メソッドを呼び出すべきではありません。Microsoft は独自の一連のガイドラインをリストしています。一番下までスクロールすると、関連するガイダンスと問題を示すコード スニペットが表示されます (メソッドを使用して説明していますが、.NET プロパティは本質的に特別なメソッドであると述べました)。
プロパティセッターを介してパラメーターを渡すと、検証コードを1か所にのみ保持できます。
実際の実装によって正確な条件が決まりますが、プライベート フィールドに直接送信するのではなく、プロパティに送信することをお勧めします。たとえば、プロパティを使用するときに発生するイベントがあり、コンストラクター中にそれらのイベントを発生させたくない場合があります。または、他の理由でプロパティ ロジックを回避したい場合もあります。
プロパティ セッターの使用には注意してください。予期しない副作用を引き起こす可能性のあるコードがセッターに含まれている可能性があります。
コンストラクター内でフィールドを操作します。フィールドは実際にはオブジェクトの固有の状態を表しており、コンストラクターの仕事はこの内部状態を初期化することです。プロパティはカプセル化の目的でここにあり、オブジェクト状態へのパブリック インターフェイスの一部です。
オブジェクトの内部状態を設定する前に、コンストラクターの引数またはプロパティの入力値に適用する変換ロジックは、大きく異なる可能性があります。とにかく、そうであれば、プロパティ セッターでコンストラクターを直接チェーンする代わりに、プロパティ セッターとコンストラクターから呼び出される明示的な変換メソッドを使用していました。
ロジックがまったくない場合、コンストラクター内でプロパティ セッターを使用する理由がわかりません。