3

シナリオを描くために、次のロジック省略サービスを検討してください

public class Service {
   private Validator validator;

   public void submit(Foo foo) {
      if (!validator.isValid(foo)) {
         log.warn("invalid foo");
      } ...
   }
}

public interface Validator {
   boolean isValid(Foo foo);
}

問題は、検証が失敗する理由を知っているのはそれ自体だけであるということです。その理由でチューニングするための実行可能なアプローチは2つしかありません。どちらかValidorValidator

  • 失敗した状態自体をログに記録します
  • 文字列の理由とブール値のisValidを含む複雑なオブジェクトを返します。

前者は素晴らしいですが、Serviceロギングが実際に実行されるかどうかはわかりません。後者は、煩わしい冗長性とより複雑な使用法をもたらします。

どちらを優先するか、またはより良いアプローチがありますか？

4

1 に答える 1

2

あなたは自分自身に質問をしなければなりません：あなたのクライアントは検証失敗の理由を気にしますか？そして答えは：それは依存します。多くの場合、検証の失敗の原因を正確にエンドユーザーに通知する必要があります。その場合、「複雑な」検証結果オブジェクトを返し（ここでは例外を使用しないでください！）、基本的に文字列またはコードのコレクションをラップします（を許可するため）。オブジェクトはValidationResultビジネスオブジェクトであり、二流のヘルパーではありません。

他の状況では、オブジェクトが有効かどうかに基づいて決定を下したいだけです。呼び出し元のコード（クライアント）は、検証の内部ロジックをあまり気にすることができませんでした。有効かどうかのどちらかです。次に、ストレートbooleanメソッドに進みます。デバッグの目的で、検証メソッド内にログを追加します。必要に応じてオン/オフを切り替えます。

そして、あなたは何が最良の部分か知っていますか？2つの方法があり、クライアントコードに適した方法を使用できます。明らかに、それほど複雑でないboolean方法は、より複雑な方法に委任するだけであり、より単純なビューを提供します。

boolean isValid(Foo foo) {
    validate(foo).isValid();
}

ValidationResult validate(Foo foo) {
    //logging and "real" validation
}
于 2012-08-24T16:33:37.823 に答える