本の中のNullオブジェクトの処理に関する説明

Question

今日は例外処理についてBobさんの本を読んでいましたが、null値を渡すことから思い出されるものは、コードが混乱するためnull値を扱うべきではないということでした。私はそれと少し混乱しています。 私はいつも、メソッドは常に依存関係がnullでないことを確認する必要があると考えてきました（コンストラクタとコンストラクタでnullを指定できるようにしない限り）。私はこの方法

public void SendMessage(IEmailSender emailSender, contactList list) 
{ 
    if(emailSender == null) 
    { 
     throw new ArgumentNullException("Failed to send 
       message.",MethodBase.GetCurrentMethod().GetParameters[0].Name); 
    } 
    if(list == null) 
    { 
     throw new ArgumentNullException("Failed to send 
       message.",MethodBase.GetCurrentMethod().GetParameters[1].Name); 
    } 

    // rest of code goes here 

} 

を持っている場合、例えば は、私は何かが足りないのですか？

Answer 1

私は本を読んでいませんが、私は叔父さんが明示的なヌル参照処理に優先してNull Object Patternの使用を主張していると想像することができます。例えば

、というよりも

if(log != null) 
    log.Write("My log message"); 

あなたが代わりにWrite方法を含む​​インターフェイスを作成し、2つのこのインタフェースを実装するクラスを作成できます。NullLoggerとFileLoggerを。 NullLoggerにはメソッドの実装のための空の本体があります。私の心の中で

これはあなたの例では、あなたが持っているあなたの明示的な前提条件の検証と異なる

Answer 2

2つの視点があります。
一方では、あなたのアプローチでは、常に正確に何の発信者を言うだろう、彼はあなたの方法を呼び出すことによって間違っていました。彼はあなたの例外を得るときにすぐにそれを修正することができるので、発信者にとっては素晴らしいです。これは、第三者が使用するAPIコードを書く場所であれば、真実で有効です。

一方、メソッドを自分で呼び出す場合、例外をスローするための妥当な引数は、呼び出しコード内のcatchブロックでこの状況を処理できるようにするためです。あなたがどこかでそれを扱う理由がなければ、なぜ例外を投げるのですか？私が見る唯一の理由は、GlobalExceptionHandlerでこれらの例外をキャッチして詳細なエラーを記録することです。

ここでは、開発者がAPIを間違って使用するのを避けるためのメソッドと、メソッドのエラー結果として使用するメソッドの2つのカテゴリがあります。あなたが他の人によって使用されるAPIのコードを記述している場合

、あなたの選択は、なりボブ;-)にCleanCodeを読んでいない人のために

を聞くことがない、ボブは2つのことを示唆している。

1. が返されるメソッドを記述しないでください。（あとで不要なチェックを避けるため）。だから、代わりにこれを書いている：

var myObject = GetObjectThatDoesSomthing(); 
if(myObject != null) 
{ 
myObject.DoSomething(); 
} 

を...あなたはこれを書くことができる必要があります：

var myObject = GetObjectThatDoesSomething(); 
myObject.DoSomething(); 

クリーナー。

2。次のことを行う必要があり、メソッドの開始時に不必要な検査を避けるため、ここでのようにあなたの方法にないパスはnull：

public Point Add(Point p1, Point p2) 
{ 
    if(p1 == null) throw ArgumentException(); 
    if(p2 == null) throw ArgumentException(); 
    ... 
} 

これらのルールのポイントは次のとおりです。あなたはそれに固執するならば、あなたは持っていけないことを知っていますこれらのヌルチェックを書くとあなたのコードはより清潔で読みやすくなります。しかし、サードパーティのコードを使用している瞬間に、APIで同じルールが適用されているかどうかを知ることができないので、もう一度チェックをやり直すことになります。他の人のためのAPIを書くときと同じこと：あなたのAPIの消費者は、あなたがボブのルールを念頭に置いてコード化していることをどのように知っていますか？

Answer 3

あなたが書いているコードのタイプによって異なります。 パブリックメソッドが、使い方に精通していない幅広い開発者によって使用されるように設計されている場合は、常にパラメータをチェックして冗長な例外をスローすることができます。

同じクラスからのみ使用されるプライベートメソッドを作成している場合、または自分または共同編集者によって作成された別のフレンドリークラスによって呼び出された内部メソッドを作成している場合は、パラノイアヌルチェックを行うことはあまり意味がありません。注入設計とテストでは、インターナショナルがヌル値を取得していないことを確認する必要があります。

プライベート/内部メソッドのパラメータが引き続きNULLを取得しても、それは遅すぎます。 ArgumentNull例外フォームをプライベート/内部メソッドを投げることは、外部ユーザーが原因を解決するのを助けないため、彼はArgumentNullまたはNullReference例外を取得することに違いはありません。