関数が意図した動作を実行する前にnullチェックを実行する必要がある場合、これは悪い設計ですか？

だから、これが良いコード設計なのか悪いコード設計なのかはわからないので、私は尋ねた方が良いと思った。

クラスを含むデータ処理を行うメソッドを頻繁に作成し、メソッドで多くのチェックを行って、null参照やその他のエラーを事前に取得しないようにします。

非常に基本的な例：

// fields and properties
private Entity _someEntity;
public Entity SomeEntity => _someEntity;

public void AssignEntity(Entity entity){
    _someEntity = entity;
}
public void SetName(string name)
{
    if (_someEntity == null) return; //check to avoid null ref
    _someEntity.Name = name;
    label.SetText(_someEntity.Name);
}

そのため、毎回nullをチェックするimを見ることができます。しかし、メソッドはこのチェックを行うべきではありませんか？

たとえば、外部コードが事前にデータをクレンジングして、メソッドが以下のように検証する必要がないようにする必要があります。

 if(entity != null) // this makes the null checks redundant in the methods
 {
     Manager.AssignEntity(entity);
     Manager.SetName("Test");
 }

要約すると、メソッドを「データ検証」してからデータに対して処理するか、メソッドを呼び出す前に保証する必要があり、メソッドを呼び出す前に検証に失敗した場合はエラーをスローする（またはエラー）？

基本的な例の問題は、nullチェックではなく、サイレントフェイルです。

ヌルポインター/参照エラーは、多くの場合、プログラマーエラーです。プログラマーのエラーは、多くの場合、すぐに大声で失敗することによって最もよく対処されます。この状況で問題に対処するには、次の3つの一般的な方法があります。

1. わざわざチェックするのではなく、ランタイムにnullpointer例外をスローさせるだけです。
2. 基本的なNPEメッセージよりも優れたメッセージで例外をチェックしてスローします。

3番目のソリューションはより多くの作業を行いますが、はるかに堅牢です。

3. _someEntity無効な状態になることは事実上不可能になるようにクラスを構築します。それを行う1つの方法はAssignEntity、インスタンス化のパラメーターとしてそれを削除し、必要とすることです。他の依存性注入手法も同様に有用です。

状況によっては、実行している作業の前にすべての関数の引数の有効性をチェックすることが理にかなっている場合もあります。スペクトルのどちらの端にいるかは、問題のドメインに依存します。3番目のオプションには、呼び出し元がすべてを適切に実行することをコンパイラーに強制させることができるという点で、大きな利点があります。

3番目のオプションがオプションではない場合、私の意見では、静かに失敗しない限り、それは本当に重要ではありません。nullをチェックしないとプログラムは即座に爆発しますが、データを静かに破壊して問題を引き起こす場合は、その場でチェックして対処するのが最善です。

_someEntityどの段階でも変更できるため、SetName呼び出されるたびにテストするのが理にかなっています。結局、メソッドが最後に呼び出されてから変更されている可能性があります。ただし、コードSetNameはスレッドセーフではないため、あるスレッドでそのチェックを実行_someEntityしnull、別のスレッドで設定すると、コードはNullReferenceExceptionとにかくバーフされることに注意してください。

したがって、この問題に対する1つのアプローチは、さらに防御的になり、次のいずれかを実行することです。

1. _someEntityメソッドのローカルコピーを作成し、そのコピーを参照します。
2. ロックを使用し_someEntityて、メソッドの実行時にロックが変更されないようにします。
3. を使用し、メソッド内で発生するtry/catchすべてNullReferenceExceptionのに対して、最初のnullチェックで実行するのと同じアクション（この場合はnopアクション）を実行します。

しかし、あなたが本当にすべきなのは、立ち止まって自分自身に質問することです。あなたは実際_someEntityに上書きを許可する必要がありますか？コンストラクタを介して一度設定しないでください。そうすれば、一度だけnullチェックを行う必要があるだけです。

private readonly Entity _someEntity;

public Constructor(Entity someEntity)
{
    if (someEntity == null) throw new ArgumentNullException(nameof(someEntity));
    _someEntity = someEntity;
}

public void SetName(string name)
{
    _someEntity.Name = name;
    label.SetText(_someEntity.Name);
}

可能な場合、これはこのような状況での使用をお勧めする方法です。可能性のあるヌルを処理する方法を選択するときにスレッドセーフを意識できない場合。

おまけのコメントとして、私はあなたのコードが奇妙で改善できると感じています。すべての：

private Entity _someEntity;
public Entity SomeEntity => _someEntity;

public void AssignEntity(Entity entity){
    _someEntity = entity;
}

次のものに置き換えることができます。

public Entity SomeEntity { get; set; }

同じ機能を持ちますが、異なる名前のメソッドではなく、プロパティセッターを介してフィールドを設定できるようにしてください。

しかし、メソッドはこのチェックを行うべきではありませんか？

これはあなたの選択です。

publicメソッドを作成することで、一般の人々にメソッドを呼び出す機会を提供します。これは、常に上の暗黙の契約と一緒に来てどのようにその方法とどのようなそう際に期待するを呼び出すこと。この契約には、「はい、そうだnull、パラメータ値として渡すと、すぐに爆発する」が含まれる場合があります（含まれない場合があります）。その契約の他の部分は、「ああ、ところで：2つのスレッドがこのメソッドを同時に実行するたびに、子猫が死ぬ」かもしれません。

どのタイプの契約を設計するかはあなた次第です。重要なことは

• 便利で一貫性のあるAPIを作成し、

• 特にこれらのエッジケースの場合、適切に文書化します。

メソッドがどのように呼び出される可能性が高いケースは何ですか？

他の答えは良いです。アクセシビリティ修飾子についていくつかコメントして、それらを拡張したいと思います。最初に、null有効でない場合の対処方法：

• publicメソッドとprotectedメソッドは、呼び出し元を制御しないものです。nullが渡されたときにスローする必要があります。そうすれば、プログラムがクラッシュしないようにしたいので、決してあなたにヌルを渡さないように呼び出し元を訓練します。

• 内部および民間の方法は、あなたがあるものであるか、呼び出し元を制御します。nullが渡されたときにアサートする必要があります。その後、おそらくクラッシュしますが、少なくとも最初にアサーションを取得し、デバッガーに侵入する機会を得ました。繰り返しになりますが、発信者を傷つけないようにすることで、発信者を正しく呼び出すようにトレーニングする必要があります。

それがあれば今、あなたは何をしますか可能性がある中で渡されるヌルのために有効であること？nullオブジェクトパターンを使用すると、この状況を回避できます。つまり、型の特別なインスタンスを作成し、無効なオブジェクトが必要なときにいつでも使用することを要求します。これで、nullを使用するたびにスロー/アサートするという楽しい世界に戻りました。

たとえば、このような状況になりたくない場合：

class Person { ... }
...
class ExpenseReport { 
  public void SubmitReport(Person approver) { 
    if (approver == null) ... do something ...

コールサイトで：

// I guess this works but I don't know what it means
expenses.SubmitReport(null); 

（1）呼び出し元にnullが適切な値であることをトレーニングしているため、および（2）その値のセマンティクスが不明であるためです。むしろ、これを行う：

class ExpenseReport { 
  public static readonly Person ApproverNotRequired = new Person();
  public static readonly Person ApproverUnknown = new Person();
  ...
  public void SubmitReport(Person approver) { 
    if (approver == null) throw ...
    if (approver == ApproverNotRequired) ... do something ...
    if (approver == ApproverUnknown) ... do something ...

そして今、通話サイトは次のようになります。

expenses.SubmitReport(ExpenseReport.ApproverNotRequired);

そして今、コードの読者はそれが何を意味するかを知っています。

他の答えは、あなたのコードがある場所でnullチェックを必要としないようにクリーンアップできることを指摘していますが、次のサンプルコードを検討するための有用なnullチェックの一般的な答えについては：

public static class Foo {
    public static void Frob(Bar a, Bar b) {
        if (a == null) throw new ArgumentNullException(nameof(a));
        if (b == null) throw new ArgumentNullException(nameof(b));

        a.Something = b.Something;
    }
}

これにより、メンテナンスの利点が得られます。何かがnullオブジェクトをメソッドに渡すコードに欠陥が発生した場合、どのパラメーターがnullであったかに関するメソッドから有用な情報を取得します。チェックを行わないと、次の行でNullReferenceExceptionが発生します。

a.Something = b.Something;

（（Somethingプロパティが値型である場合）aまたはbのいずれかがnullになる可能性があり、スタックトレースからどれを知ることができなくなります。チェックにより、どのオブジェクトがヌルであったかを正確に知ることができます。これは、欠陥の選択を解除するときに非常に役立ちます。

元のコードのパターンは次のとおりです。

if (x == null) return;

特定の状況で使用できますが、コードベースの根本的な問題を隠すための非常に優れた方法を提供することもできます（より頻繁に）。

いいえ、まったく違いますが、それは異なります。

それに反応したい場合にのみ、null参照チェックを行います。

あなたがいる場合はnull参照のチェックを行うと、チェック例外をスローし、あなたはそれに反応し、彼が回復することを可能にする方法をユーザーに強制します。プログラムは期待どおりに動作します。

null参照チェックを行わない（または未チェックの例外をスローする）場合、NullReferenceException通常はメソッドのユーザーによって処理されず、アプリケーションをシャットダウンする可能性があるuncheckedをスローする可能性があります。これは、関数が明らかに完全に誤解されているため、アプリケーションに障害があることを意味します。

@nullの答えを拡張したものですが、私の経験では、何があってもnullチェックを実行します。

優れた防御的プログラミングとは、プログラム全体がクラッシュしようとしているという前提で、現在のルーチンを単独でコーディングするという姿勢です。失敗が選択肢にならないミッションクリティカルなコードを書いている場合、これがほとんど唯一の方法です。

さて、実際にnull値をどのように扱うかは、ユースケースに大きく依存します。

nullが許容値、たとえばMSVCルーチン_splitpath（）の2番目から5番目のパラメータのいずれかである場合、それを静かに処理するのが正しい動作です。

null問題のルーチンを呼び出したときに起こるべきではない場合、つまり、OPの場合、APIコントラクトがAssignEntity()有効な状態で呼び出される必要がある場合、Entity例外をスローするか、そうでなければプロセスで多くのノイズを発生させます。

nullチェックのコストを心配する必要はありません。発生した場合、それらは安価であり、最新のコンパイラーでは、静的コード分析は、コンパイラーが発生しないと判断した場合に完全に排除できます。