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);
}

问题是只有它Validor自己知道验证失败的原因。我只看到了两种可行的方法来调整这个原因。无论是Validator

  • 记录失败条件本身
  • 返回一个包含字符串原因和布尔值isValid的复杂对象。

前者很好，但会让人Service不知道是否实际执行了日志记录，而后者引入了烦人的冗余和更复杂的用法。

哪个更喜欢，或者，有更好的方法吗？

4

1 回答 1

2

您必须问自己一个问题：您的客户是否关心验证失败的原因？答案是：这取决于. 在许多情况下，您希望准确地告知最终用户验证失败的原因。在这种情况下，返回“复杂”的验证结果对象（这里不要使用异常！），本质上是包装字符串或代码的集合（以允许）。该ValidationResult对象将是一个业务对象，而不是一些二等助手。

在其他情况下，您只想根据对象是否有效做出决定。调用代码（客户端）不太关心验证的内部逻辑。它是有效的还是无效的。然后走直线boolean法。出于调试目的，在验证方法中添加日志记录。根据您的需要打开/关闭它们。

你知道最好的部分是什么吗？您可以有两种方法并使用更适合客户端代码的方法。显然，不太复杂的boolean方法只委托给更复杂的方法并提供更简单的视图：

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

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