を実装しDelegateCommandていますが、コンストラクターを実装しようとしていたときに、次の2つの設計の選択肢を思いつきました。

1：複数のオーバーロードされたコンストラクターを持つ

public DelegateCommand(Action<T> execute) : this(execute, null) { }

public DelegateCommand(Action<T> execute, Func<T, bool> canExecute)
{
    this.execute = execute;
    this.canExecute = canExecute;
}

2：オプションのパラメーターを持つコンストラクターを1つだけ持つ

public DelegateCommand(Action<T> execute, Func<T, bool> canExecute = null)
{
    this.execute = execute;
    this.canExecute = canExecute;
}

どちらを使用するかわからないのは、提案された2つの方法のいずれかにどのような利点/欠点があるかわからないからです。両方とも次のように呼び出すことができます：

var command = new DelegateCommand(this.myExecute);
var command2 = new DelegateCommand(this.myExecute, this.myCanExecute);

誰かが私を正しい方向に向けてフィードバックをお願いできますか？

デフォルト値よりも複数のコンストラクターの方が好きです。個人的には、2つのコンストラクターの例は好きではありません。異なる方法で実装する必要があります。

複数のコンストラクターを使用する理由は、他のコンストラクターがメインのコンストラクターにデフォルト値を提供できるのに対して、メインのコンストラクターはすべてのパラメーターがnullではないかどうか、およびそれらが有効かどうかをチェックできるからです。

ただし、例では、2次コンストラクターでもnullaをデフォルト値として渡し、1次コンストラクターもデフォルト値を認識している必要があるため、それらの間に違いはありません。すべきではないと思います。

これは、次のように実装すると、よりクリーンで、より適切に分離されることを意味します。

public DelegateCommand(Action<T> execute) : this(execute, _ => true) { }

public DelegateCommand(Action<T> execute, Func<T, bool> canExecute)
{
    this.execute = execute ?? throw new ArgumentNullException(..);
    this.canExecute = canExecute ?? throw new ArgumentNullException(..);
}

_ => trueプライマリコンストラクターに渡されることに注意してください。このコンストラクターは、すべてのパラメーターのチェックも行ってnullおり、デフォルトを気にしません。

ただし、最も重要な点は拡張性です。将来コードを拡張する可能性がある場合、複数のコンストラクターの方が安全です。さらに必要なパラメータを追加し、オプションのパラメータを最後に追加する必要がある場合、現在のすべての実装を中断します。古いコンストラクタ[Obsolete]を作成して、すぐにコードを壊すことなく新しい実装に移行する時間を与えて、削除されることをユーザーに通知できます。

一方、あるシナリオでいくつかのパラメーターが必要で、別のシナリオではオプションのパラメーターが必要な場合は、単にパラメーターを見て適切なコンストラクターを選択するのではなく、ドキュメントを調べる必要があるため、オプションのパラメーターを多すぎると混乱させることにもなります。

コンストラクターで行うのは単純な割り当てだけであると考えると、単一のコンストラクターソリューションがあなたの場合により良い選択であるかもしれません。もう1つのコンストラクターは追加の機能を提供しません。2つのパラメーターを持つコンストラクターの設計から、2番目の引数を指定する必要がないことは明らかです。

複数のコンストラクターは、異なる型からオブジェクトを構築するときに意味があります。その場合、コンストラクタは入力パラメーターを処理し、構築中のクラスの正しい内部プロパティ表現にフォーマットするため、外部ファクトリーの代わりになります。しかし、それはあなたの場合には起こらないので、単一のコンストラクタで十分なはずです。

それぞれのアプローチが輝ける2つの異なるケースがあると思います。

まず、単純なコンストラクターがある場合（私の経験では通常そうです）、オプションの引数を使用することを検討します。

1. それらは、書かなければならないコードを最小限にします（したがって、読まなければなりません）。
2. ドキュメントを1か所にまとめて、繰り返さないようにすることができます（これは、古くなる可能性のある余分な領域を開くため、悪いことです）。
3. オプションの引数が多数ある場合、コンストラクターの非常に複雑な組み合わせのセットを避けることができます。ヘック、2つのオプション引数（互いに関連しない）だけでも、別々のオーバーロードされたコンストラクタが必要な場合、4つのコンストラクタ（バージョンなし、バージョンあり、バージョンあり）が必要になります。これは明らかにうまくスケーリングしません。

Buuuut、コンストラクターのオプションの引数が物事を明らかに混乱させるだけの場合があります。明らかな例は、これらのオプションの引数が排他的である（つまり、一緒に使用できない）場合です。引数の実際に有効な組み合わせのみを許可するコンストラクターをオーバーロードすると、この制約のコンパイル時の実施が保証されます。そうは言っても、このケースに出くわすことも避けなければなりません（たとえば、各クラスが排他的な動作を行うベースから継承する複数のクラスがある場合）。