クラスを設計するとき、有効な状態を維持するためのロジックは、クラス内またはクラス外に組み込む必要がありますか? つまり、プロパティは無効な状態 (範囲外の値など) で例外をスローする必要がありますか、またはクラスのインスタンスが構築/変更されているときにこの検証を実行する必要がありますか?
3250 次
8 に答える
13
それはクラスに属しています。クラス自体 (およびクラスが委任するすべてのヘルパー) 以外は、有効または無効な状態を決定するルールを知っているか、関与する必要があります。
于 2009-07-13T22:04:04.283 に答える
4
はい、プロパティは設定時に有効/無効な値をチェックする必要があります。それがそのためです。
于 2009-07-13T22:06:15.323 に答える
3
外部のコードに関係なく、クラスを無効な状態にすることは不可能であるべきです。それはそれを明確にするはずです。
一方、その外側のコードは、クラスを正しく使用する責任があるため、頻繁に 2 回チェックすることが理にかなっています。クラスのメソッドは、好きではない何かが渡された場合にスローする可能性がArgumentExceptionあり、呼び出し元のコードは、入力を検証するための適切なロジックを配置するなどして、これが発生しないようにする必要があります。
システムに関与するクライアントの「レベル」が異なる、より複雑なケースもあります。例はOSです。アプリケーションは「ユーザーモード」で実行され、OSを無効な状態にすることはできません。しかし、ドライバーは「カーネル モード」で実行され、アプリケーションによって使用されるサービスの実装を担当するチームの一部であるため、OS の状態を完全に破壊する可能性があります。
この種の二重レベルの配置は、オブジェクト モデルで発生する可能性があります。有効な状態のみを参照するモデルの「外部」クライアントと、そうでなければ「無効な」状態と見なされるものを参照できる必要がある「内部」クライアント (プラグイン、拡張機能、アドオン) が存在する可能性があります。状態遷移を実装する際に果たす役割があるためです。無効/有効の定義は、クライアントが果たす役割によって異なります。
于 2009-07-13T22:12:01.460 に答える
2
通常、これはクラス自体に属しますが、「有効」の定義にもある程度依存する必要があります。たとえば、System.IO.FileInfoクラスを考えてみましょう。存在しないファイルを参照しても有効ですか？どうやって知るのでしょうか？
于 2009-07-13T22:08:20.390 に答える
1
@Joelに同意します。通常、これはクラス内にあります。ただし、プロパティ アクセサーに検証ロジックを実装させることはありません。むしろ、オブジェクトが永続化されているときに、永続化レイヤーが呼び出す検証メソッドをお勧めします。これにより、検証ロジックを 1 か所にローカライズし、実行中の永続化操作に基づいて有効/無効の異なる選択を行うことができます。たとえば、データベースからオブジェクトを削除しようとしている場合、そのプロパティの一部が無効であることを気にしますか? おそらくそうではありません。ID と行のバージョンがデータベース内のものと同じである限り、先に進んで削除してください。同様に、挿入と更新に異なるルールを設定することもできます。たとえば、一部のフィールドは挿入時には null であるが、更新時には必要になる場合があります。
于 2009-07-13T22:15:16.413 に答える
0
クラスは実際に有効な値を維持する必要があります。これらがコンストラクターを介して入力されたのか、プロパティを介して入力されたのかは関係ありません。どちらも無効な値を拒否する必要があります。コンストラクターパラメーターとプロパティの両方で同じ検証が必要な場合は、共通のプライベートメソッドを使用してプロパティとコンストラクターの両方の値を検証するか、プロパティで検証を行い、設定時にコンストラクター内でプロパティを使用できます。ローカル変数。個人的には、一般的な検証方法を使用することをお勧めします。
無効な値を受け取った場合、クラスは例外をスローする必要があります。全体として、優れた設計は、これが発生する可能性を減らすのに役立ちます。
于 2009-07-13T22:47:48.173 に答える
0
場合によります。
検証が単純で、クラスに含まれる情報のみを使用してチェックできる場合は、ほとんどの場合、状態チェックをクラスに追加する価値があります。
ただし、そうすることが実際には不可能である、または望ましくない場合もあります。
良い例はコンパイラです。プログラムが有効であることを確認するための抽象構文ツリー (AST) の状態のチェックは、通常、プロパティ セッターまたはコンストラクターによって行われません。代わりに、検証は通常、ツリー ビジター、またはある種の「セマンティック分析クラス」の一連の相互再帰メソッドによって行われます。ただし、どちらの場合も、プロパティは値が設定されてからかなり後に検証されます。
また、オブジェクトが古い UI 状態に使用されている場合、無効な値が設定されている場合に例外をスローするのは (使いやすさの観点から) 通常はお勧めできません。これは特に、WPF データ バインディングを使用するアプリに当てはまります。その場合、例外をスローするのではなく、ある種のモードレス フィードバックを顧客に表示する必要があります。
于 2009-07-13T22:16:23.570 に答える