C＃でのコンストラクターパラメーターの検証-ベストプラクティス

コンストラクターパラメーターの検証のベストプラクティスは何ですか？

単純なC＃を想定します。

public class MyClass
{
    public MyClass(string text)
    {
        if (String.IsNullOrEmpty(text))
            throw new ArgumentException("Text cannot be empty");

        // continue with normal construction
    }
}

例外をスローすることは受け入れられますか？

私が遭遇した代替案は、インスタンス化する前の事前検証でした：

public class CallingClass
{
    public MyClass MakeMyClass(string text)
    {
        if (String.IsNullOrEmpty(text))
        {
            MessageBox.Show("Text cannot be empty");
            return null;
        }
        else
        {
            return new MyClass(text);
        }
    }
}

私はコンストラクタですべての検証を実行する傾向があります。ほとんどの場合不変オブジェクトを作成するため、これは必須です。あなたの特定の場合、これは受け入れられると思います。

if (string.IsNullOrEmpty(text))
    throw new ArgumentException("message", "text");

.NET 4を使用している場合、これを行うことができます。もちろん、これは、空白のみを含む文字列を無効とみなすかどうかによって異なります。

if (string.IsNullOrWhiteSpace(text))
    throw new ArgumentException("message", "text");

多くの人々は、コンストラクターが例外をスローすべきでないと述べています。たとえば、このページの KyleG はまさにそれを行います。正直なところ、なぜそうなのか、私には考えられません。

C ++では、コンストラクターから例外をスローするのは悪い考えです。なぜなら、参照していない初期化されていないオブジェクトを含む割り当てられたメモリが残るからです（つまり、古典的なメモリリークです）。それはおそらくスティグマの由来です-昔ながらのC ++開発者の束がC＃の学習を半分中断し、C ++から得た知識をそのまま適用しました。対照的に、Objective-Cでは、Appleは割り当てステップを初期化ステップから分離したため、その言語のコンストラクターは例外をスローできます。

C＃は、コンストラクターの呼び出しに失敗してもメモリをリークできません。.NETフレームワークの一部のクラスでさえ、コンストラクターで例外をスローします。

クラスをそのセマンティックの使用に関して一貫した状態にすることができない例外IFFをスローします。それ以外の場合はしないでください。オブジェクトが矛盾した状態で存在することを許可しないでください。これには、完全なコンストラクターを提供しないことも含まれます（オブジェクトが実際に完全に構​​築される前に空のコンストラクター+ initialize（）を用意するなど）...

ピンチで、誰もがそれを行います。先日、狭い範囲内で非常に狭く使用されるオブジェクトに対してそれを行いました。いつか、私や他の誰かが実際にそのスリップの代価を払うでしょう。

「コンストラクタ」とは、オブジェクトを構築するためにクライアントが呼び出すものを意味することに注意してください。これは、「Constructor」という名前の実際の構成体とは別の簡単なものです。たとえば、C ++のこのようなものは、IMNSHOの原則に違反しません。

struct funky_object
{
  ...
private:
  funky_object();
  bool initialize(std::string);

  friend boost::optional<funky_object> build_funky(std::string);
};
boost::optional<funky_object> build_funky(std::string str)
{
  funky_object fo;
  if (fo.initialize(str)) return fo;
  return boost::optional<funky_object>();
}

を作成する唯一の方法funky_objectはbuild_funky、実際の「コンストラクタ」がジョブを終了しなくても、無効なオブジェクトの存在を許可しないという原則を呼び出すことです。

疑わしい利益（損失かもしれません）のために、それは多くの余分な仕事です。私はまだ例外ルートを好むでしょう。

この場合、ファクトリメソッドを使用します。基本的に、クラスにはプライベートコンストラクターのみを設定し、オブジェクトのインスタンスを返すファクトリメソッドを設定します。初期パラメーターが無効な場合は、nullを返し、呼び出し元のコードに処理を決定させるだけです。

public class MyClass
{
    private MyClass(string text)
    {
        //normal construction
    }

    public static MyClass MakeMyClass(string text)
    {
        if (String.IsNullOrEmpty(text))
            return null;
        else
            return new MyClass(text);
    }
}
public class CallingClass
{
    public MyClass MakeMyClass(string text)
    {
        var cls = MyClass.MakeMyClass(text);
        if(cls == null)
             //show messagebox or throw exception
        return cls;
    }
}

条件が例外でない限り、例外をスローしないでください。この場合、空の値を簡単に渡すことができると考えています。その場合、このパターンを使用すると、MyClassの状態を有効に保ちながら例外とそれらが被るパフォーマンスのペナルティを回避できます。

• コンストラクターには副作用がありません。
  • プライベートフィールドの初期化以外のものは、副作用として見なされる必要があります。
  • 副作用のあるコンストラクターは、単一責任原則（SRP）を破り、オブジェクト指向プログラミング（OOP）の精神に反して実行されます。
• コンストラクターは軽量で、失敗することはありません。
  • たとえば、コンストラクター内にtry-catchブロックが表示されると、私は常に身震いします。コンストラクターは、例外をスローしたり、エラーをログに記録したりしないでください。

これらのガイドラインに合理的に疑問を呈し、「しかし、私はこれらの規則に従わず、私のコードは正常に動作します！」と言うことができます。それに対して、「そうでないまで、それは本当かもしれません。」と答えます。

• コンストラクター内の例外とエラーは非常に予期しないものです。そうするように言われない限り、将来のプログラマーは、これらのコンストラクター呼び出しを防御的なコードで囲む傾向がなくなります。
• 本番環境で何かが失敗すると、生成されたスタックトレースの解析が困難になる場合があります。スタックトレースの最上部はコンストラクター呼び出しを指している場合がありますが、コンストラクターで多くのことが発生し、失敗した実際のLOCを指し示していない場合があります。
  • これが当てはまる場合、多くの.NETスタックトレースを解析しました。

MyClassの動作に依存します。MyClassが実際にデータリポジトリクラスであり、パラメータテキストが接続文字列である場合、ベストプラクティスはArgumentExceptionをスローすることです。ただし、MyClassがStringBuilderクラスの場合（たとえば）、空白のままにしておくことができます。

それは、パラメータテキストがメソッドにとってどれだけ重要であるかに依存します。オブジェクトは、nullまたは空白の値で意味をなしますか？

私の好みはデフォルトを設定することですが、Javaにはこのようなことをする「Apache Commons」ライブラリがあり、それもかなり良い考えだと思います。無効な値によってオブジェクトが使用不可能な状態になる場合、例外をスローする問題は見当たりません。文字列は良い例ではありませんが、もしそれが貧乏人のDIの場合はどうでしょうか？インターフェイスnullの代わりにの値が渡された場合、操作できませんでしたICustomerRepository。このような状況では、例外をスローすることが物事を処理する正しい方法です。

私がc ++で作業していたとき、メモリリークの問題が発生する可能性があるため、コンストラクタで例外をスローすることはしませんでした。C ++を使用している人は誰でも、メモリリークがどれほど困難で問題があるかを知っています。

ただし、c＃/ Javaを使用している場合は、ガベージコレクターがメモリを収集するため、この問題は発生しません。C＃を使用している場合、データ制約が保証されていることを確認するために、プロパティを使用することをお勧めします。

public class MyClass
{
    private string _text;
    public string Text 
    {
        get
        {
            return _text;
        } 
        set
        {
            if (string.IsNullOrWhiteSpace(value))
                throw new ArgumentException("Text cannot be empty");
            _text = value;
        } 
    }

    public MyClass(string text)
    {
        Text = text;
        // continue with normal construction
    }
}

例外をスローすることは、クラスのユーザーにとって大きな苦痛になります。検証が問題である場合、通常、オブジェクトの作成を2ステップのプロセスにします。

1-インスタンスを作成します

2-戻り結果でInitializeメソッドを呼び出します。

または

検証を実行できるクラスを作成するメソッド/関数を呼び出します。

または

isValidフラグがあります。これは特に好きではありませんが、一部の人は気に入っています。