コンテクスト検証
2005年12月7日
私が執筆する中で、ずっとバリデーションに関する資料を書くという意向でした。バリデーションは混乱をもたらす領域であり、有効に機能する手法について具体的な説明を得られると良いです。しかし、人生には書くべきことがたくさんあり、時間が許すよりも多くのものを書くべきです。
最近読んだ内容により、このトピックについて予備的な話を少しするのは良いと考えました。多くの人が実施している一般的なことは、オブジェクトのバリデーションルーチンを開発することです。これらのルーチンにはさまざまな種類があります。オブジェクト内またはオブジェクト外に配置したり、失敗を示すためにブーリアン値を返したり、例外をスローしたりできます。ただし、isValid
メソッドなどが示す方法で、オブジェクトの検証をコンテキストに依存しない方法で行おうとすると、人々が常に障害に直面することがあると思います。
検証をアクション(通常は実行したいアクション)にバインドされたものとして考えるべきだと考えています。この注文は記入しても良いものか、この顧客はホテルにチェックインしても良いものか。そのため、isValid
などのメソッドではなく、isValidForCheckIn
などのメソッドを使用します。
この結果の1つは、オブジェクトをデータベースに保存すること自体がアクションであるということです。これについて考えると、いくつかの重要な問題が生じます。人々がコンテキストフリーの検証について話す場合、それはデータベースに保存するという観点から意味していることがよくあります。ただし、これを作成するさまざまな検証チェックに「このテストに失敗すると保存を妨げる必要があるか」という質問を照会する必要があります。
About Faceのなかで、Alan Cooper氏は、ユーザーによる無効状態の入力を禁止すべきではない(無効状態の情報を保存すべきではない)と主張しています。数日前にJimmy Nilssonが書いている本のドラフトを読んでいたとき、このことが思い出させられました。彼は、オブジェクトにエラーが含まれていても、常にオブジェクトを保存できるべきだと主張していました。私はこれが絶対的なルールになるべきだとは確信していませんが、実際、人々は正当な理由なく保存を禁止する傾向にあります。検証のコンテキストについて考えることで、そのようなことを防ぐことができます。
2011年11月3日に転送