コンストラクタデータを検証する

Question

"C＃Class Desing Handbook"（Pg 137）のサンプルクラスは、クラスのみのコンストラクタの中から特定のフィールドのクラス検証メソッドを呼び出しません。したがって、基本的にサンプルクラスを使用すると、不正なデータを持つオブジェクトを作成し、検証を行うフィールドのプロパティを呼び出すときにそのデータに対してエラーをスローするだけです。だからあなたは今、悪いものを持っていて、事実の後まで知ることはできません。

初期化時に不正なデータが見つかった場合に、コンストラクタからプロパティを呼び出すだけでエラーが発生するのはなぜですか？

私のコンストラクタから自分のプロパティを呼び出すと、次のようなフォーマットが使用される傾向があります。これは、初期化データを検証するための適切な構造ですか？ TY

class Foo 
{ 
    private string _emailAddress; 

    public Foo(string emailAddress) 
    { 
     EmailAddress = emailAddress; 
    } 

    public string EmailAddress 
    { 
     get { return _emailAddress; } 
     set 
     { 
      if (!ValidEmail(value)) 
       throw new ArgumentException 
        (string.Format 
        ("Email address {0} is in wrong format", 
        value)); 

      _emailAddress = value; 
     } 
    } 


    private static bool ValidEmail(string emailAddress) 
    { 
     return Regex.IsMatch 
      (emailAddress, @"\b[A-Z0-9._%+-]+" + 
          @"@[A-Z0-9.-]+\.[A-Z]{2,4}\b", 
          RegexOptions.IgnoreCase); 
    } 
} 

Answer 1

EMAILADDRESSは、任意のレベルでnullの場合は、チェックされていないので、まあ、1のために、あなたは、恐ろしいとNullReferenceExceptionを取得する可能性があります。この特定のチェックはコンストラクタ自体で実行する必要があり、emailAddressがnullの場合はArgumentNullExceptionをスローします。残りの部分については、あなたのサンプルに書かれているように、特に問題はありません。ただし、プロパティを仮想化してこのクラスから子を派生させると、いくつかの問題が発生する可能性があります。フィールド初期化、基本クラス、派生クラスのコンストラクタの実行順序が問題になり、注意が必要です。

Answer 2

このアプローチでは何も問題ありません。コンストラクタ内でこのメソッドを呼び出すことができます。プロパティのsetter/getterは、メソッド呼び出しの文法的な砂糖です。

Answer 3

はい、あなたの一般的なアプローチがある場合：

すると、だけにして、私はそれを愛する

validオブジェクトのインスタンスを取得することができていることを確認してください。

コンストラクタに入れるべきもののために、単に「コンテナ」を作成するのではなく、すぐに有効なオブジェクトを作成するために使用されなければならない。

Answer 4

メールアドレスが設定されているとき、検証が起こっています。これは後で電子メールアドレスを再設定する可能性があるため、必要な場所です。

コンストラクタで検証とも呼ばれる場合は、追加の冗長な検証呼び出しを行います（構築時には1回、コンストラクタでは電子メールアドレスが設定されている場合はもう1回）。

Answer 5

コンストラクタ内のデータを検証しないことは意味がありません。あなたが指摘しているように、オブジェクトは無効な状態になる可能性があります。この設計を考えると、ゲッターを呼び出すときに悪いデータがあることに気付かないでしょう。

中度以上のものについては、すぐに例外をスローするのではなく、壊れたルールのアプローチを使用する傾向があります。このアプローチでは、無効なクラスとプロパティに関する情報と無効な理由を含むBrokenRulesオブジェクトを定義します。次に、共通の基底クラスで、オブジェクトの「間違った」すべてのリストを保持するListを定義します。 （ベースクラスの）プロパティであるIsValidは、現在破損しているルールがあるかどうかを示します。

この利点は、オブジェクト状態にいくつかの問題がある可能性があることです。ユーザーが問題を解決するように求められている場合（つまり、このオブジェクトはUIから設定されます）、すべての問題のリストを提供することで、ユーザーは1つのエラーを修正するのではなく、1つのエラーを修正することができます。もう一つ。等