optimization - ゲッター/セッターまたは他の場所でのデータ検証?

Question

getterとsetter、またはコードの他の場所で検証を行うことをお勧めします。

コードの最適化と高速化に関しては、これは驚くかもしれませんが、ゲッターとセッターではなく、ファイルまたはデータベースを更新しているコードで検証を行うべきだと思います。私が間違っている？

score 15 · Accepted Answer

クラスが通常、パブリックゲッター/セッターを持つプライベートメンバーを含む理由の 1 つは、データを検証できるからです。

1 から 100 までの数値がある場合は、それを検証するセッターに何かを入れて、コードによってキャッチされている例外をスローする可能性があります。理由は単純で、セッターでやらないと1～100の制限を設定するたびに覚えないとコードが重複したり、忘れると無効状態になってしまうからです。

パフォーマンスに関しては、私はここでクヌースと一緒です：

「私たちは小さな効率を忘れるべきです。たとえば、約 97% の確率で: 時期尚早の最適化はすべての悪の根源です。」

score 4 · Accepted Answer

@テラピン、再：

あなたが持っているのが[simplepublicset / get]プロパティの束だけである場合、それらはフィールドである可能性もあります

プロパティには、フィールドに比べて他の利点があります。これらはより明示的なコントラクトであり、シリアル化されており、後でデバッグできます。継承による拡張に最適な場所です。不格好な構文は偶然の複雑さです。たとえば、.net3.5はこれを克服します。

一般的な（そして欠陥のある）慣行は、パブリックフィールドから始めて、後で「必要に応じて」プロパティに変換することです。これはあなたのクラスを消費する人との契約を破るので、プロパティから始めるのが最善です。

score 3 · Accepted Answer

コードを最も保守しやすいという観点から、プロパティのセッターでできる限り多くの検証を行う必要があると思います。この方法では、無効なデータをキャッシュしたり、処理したりすることはありません。

結局のところ、これがプロパティの目的です。あなたが持っているのが次のようなプロパティの束だけである場合...

public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}

...それらはフィールドである可能性もあります

score 3 · Accepted Answer

場合によります。

通常、コードはすぐに失敗するはずです。コード内の複数のポイントで値を設定でき、値を取得した後にのみ検証する場合、バグは更新を行うコードにあるようです。セッターが入力を検証する場合、どのコードが無効な値を設定しようとしているかがわかります。

score 1 · Accepted Answer

私は自分のオブジェクトが無効な状態にならないように努めているので、セッターは間違いなく検証と、状態を変更するすべてのメソッドを持っています。このようにして、扱っているオブジェクトが無効であると心配する必要はありません。メソッドをバリデーションの境界として保持すれば、バリデーションフレームワークや IsValid() メソッドの呼び出しがあちこちに散らばっていることを心配する必要はありません。

score 1 · Accepted Answer

IDataErrorInfoを実装し、検証ロジックをその Error および this[columnName] プロパティに配置するのが好きです。そうすれば、エラーがあるかどうかをプログラムで確認したい場合は、コードでこれらのプロパティのいずれかをテストするか、Web フォーム、Windows フォーム、または WPF のデータバインディングに検証を渡すことができます。

WPF の "ValidatesOnDataError" Binding プロパティを使用すると、これが特に簡単になります。

score 1 · Accepted Answer

検証は、検証メソッドのゲッターまたはセッターとは別にキャプチャする必要があります。そうすれば、検証を複数のコンポーネントで再利用する必要がある場合に利用できます。

セッターが呼び出されると、そのような検証サービスを利用して、オブジェクトへの入力をサニタイズする必要があります。これにより、オブジェクトに格納されているすべての情報が常に有効であることがわかります。

オブジェクトに関する情報はすでに有効であると信頼されているため、ゲッターの検証は必要ありません。

データベースが更新されるまで検証を保存しないでください!! はやく失敗したほうがいい。

score 1 · Accepted Answer

Eric Evans によるDomain Driven Designをチェックしてみてください。DDD には、次の仕様の概念があります。

... 特殊な目的のための明示的な述語のような VALUE OBJECTS。SPECIFICATION は、オブジェクトがある基準を満たしているかどうかを判断する述語です。

速く失敗することは 1 つのことだと思います。もう 1 つは、検証用のロジックをどこに保持するかということです。ドメインはロジックを保持するのに適した場所であり、仕様オブジェクトまたはドメインオブジェクトの検証メソッドが適切な場所になると思います。

optimization - ゲッター/セッターまたは他の場所でのデータ検証?

8 に答える 8

Related

Reference