私は実際に簡単にデバッグできる再利用可能なコードのベストプラクティスを理解しようとしています。私はまだよく理解していない開発者の間で共通の練習をしてきました。コンストラクタのNullのチェック
public MyConstructor(Object myObject)
{
if (myObject == null)
throw new ArgumentNullException("myObject is null.");
_myObject = myObject;
}
ほとんどの場合、このチェックは不要です。しかし、私はそれがこのチェックを行う利点が何であるか完全に理解していないからだと思う。とにかくnull参照例外がスローされるようだ？私はおそらく間違っている、本当にそれについてのいくつかの考えを聞きたい。
ありがとうございます。
コンパイラはオブジェクトの値を知らないので、実行時にこれをチェックしてヌル値で呼び出されないようにする必要があります。
これはまた、お使いのソリューションによって異なります。例外をスローする必要はありません。その値をnullにできない場合にのみスローし、nullの場合は例外です。
nullをチェックする必要があるかどうかは一般的には言えません。むしろあなたはnull値の変数で生きることができるかどうかに依存します。 Null自体は悪い状態ではありません。変数がnullで、それ以外の変数が許される状況があるかもしれません。
null値を許可するかどうかを判断し、それに応じてコンストラクタを設計するのが適切かどうかを確認してください。
nullオブジェクトを渡すことは、多くの場合完全に合法です。このクラスでは、実装者は有効なObjectインスタンスを渡すことなくクラスのインスタンスを作成できないようにしたいので、後でチェックする必要はありませんこれをコンストラクタにできるだけ早く確実に行うのが良い方法です。
コンパイラが認識できないため、nullを明示的にチェックする必要がありますが、nullも有効な引数になる可能性があるためです。
オブジェクトの構築時に例外がスローされるため、コードのどの部分が原因であるかを簡単にトレースできます。あなたのコードが非ヌルmyobject値を必要とし、あなたは、コンストラクタでそれを検証していない場合は、myObject_を使用し、あなたがそのヌル値を送った人を確認するために戻って手動でトレースする必要がありますとき、NullReferenceExceptionがスローされます。
あなたの場合：
public ctor(IEnjection ninjaWeapon)
{
Contract.Requires<ArgumentNullException>(ninjaWeapon != null);
this.deadlyWeaponary.Add(ninjaWeapon);
}
ます場合は、古いバージョンでは、同じことを行うにはMicrosoft.Contractを参照します。
+1 ninjaWeaponの使用 – ninjasense
あなたがやっていることは必須ではありません。オブジェクトを参照する前に、nullではないことを確認することができます。もちろん、オブジェクトが初期化されたときに使用するものを検証することは、非常に有効なアプローチです。 –
@Ramhound - これは、StructureMapなどのDIフレームワークを使用する場合、コンストラクタに渡される内容を直接制御する必要がない場合の一般的なアプローチです。あなたのクラスが 'myObject'なしで無駄であり、これを初期化する唯一の場所であれば、できるだけ早く例外をスローしてそれらについて知ることができます。長時間実行されているWebアプリケーションでは、誰かがオブジェクトを必要とするメソッドを呼び出すまで、問題についてはわからないことがあります。 –