validation - 単純な検証ロジックの仕様を使用する必要がありますか?

Question

私は最近仕様について読んでいて、それらを使用することに本当に熱心です. ただし、やりすぎるのは怖いです。

たとえば、電話番号プロパティを持つ User エンティティがある場合、電話番号仕様テストをセッターに入れる必要がありますか?それともセッターの検証ロジックで十分ですか?

ありがとう、フィル

更新： より多くのコンテキストについて：検証はプレゼンテーションではなくドメインで行いたいと思います。プレゼンテーションに検証を実装しますが、それはより多くの UI 機能になります。アイデア (私は信じています) は、ドメインが無効な状態になることも、プレゼンテーションに依存することもできないということです。私は実際に電話番号エンティティを持っており、多くのエンティティが電話番号を持っていますが、これはオブジェクトを評価できると思いますが、それは別の議論です:)

プロパティセッターで仕様を使用するのはやり過ぎかどうか疑問に思っていました。私が見た利点の 1 つは、検証コードを共有できるように、仕様をレイヤー (つまりプレゼンテーション層) 間で共有できることです。

ご覧のとおり、これが正しいアプローチであるかどうかはわかりません。

どうもありがとう、フィル

Answer 1

事前条件と事後条件 (不変条件または契約による設計) の概念を調べることができます。事前条件は、関数が正しく動作するために真でなければならないものです。事後条件は、関数が完了して正常に終了したときに true になるものです。

「ユーザーの電話番号が有効」は、おそらくセッター関数に適した事後条件です。ただし、前提条件には 2 つの選択肢があります。(1) セッター関数に渡されたものはすべて有効であることをセッター関数の前提条件にするか、(2) セッター関数に対してはるかに緩い前提条件を作成し、エラー チェックを実行します。セッター関数で。オプション (1) は、基本的に検証の責任をクライアントに渡します。オプション (2) は、ユーザー エンティティにエラー処理の責任を与えます。

選択するデザインは、特定のアプリケーションの全体像に依存すると思います.

不変 条件と契約による設計へのリンクを次に示します 。