是否“只说，不问”？ 适用于用户输入验证？

Question

这些年来我一定忽略了“告诉，不要问”OOP 原则，因为我几天前才第一次了解到它。

但上下文是关于验证代码的讨论，验证代码已从 ASP.NET Web 表单页面移出并移至数据/业务对象中，并且没有“Validate()”方法，只有一个本身执行验证和操作的保存方法（据说）提出了一个例外。 我问为什么要这样设计，我被引导到 OOP 的“告诉，不要问”原则，这是我从未听说过的，所以然后我们一起查看了 Google，我立即就受到了教育。 ；）

不过，有些东西听起来不太对劲，在数据从用户手中移交给业务层并在其中进行处理和/或收集之前，不应该对其进行清理，而不是相反？ 我很困惑这如何能带来好的设计。

似乎“告诉，不要问”的规则属于这样的想法，即您不应该向目标对象询问目标对象的状态，并且该原则从未真正适用于传递的数据到目标对象。

Answer 1

我认为这听起来像是一堆“最佳实践”和“设计方法”出了问题，但现在对我来说有点有意义。 这样看：

想象一下将验证放在业务对象中，但将“如果验证失败该怎么办”放在表示层中。这将允许多个不同的表示层重用相同的验证逻辑，但以不同的方式处理错误。

公共 Foo 
  { 
    验证（Baz 栏） 
    { 
        if(!is_number(bar)) 抛出 numberException(); 
    } 

    分配栏（Baz栏） 
    { 
        验证（栏）； 
    } 
  } 


  //... 

  尝试 
  { 
    foo.AssignBar(bar); 
  } 
  catch(数字异常 e) 
  { 
    Alert('不是数字！'); 
  } 
  

注意，您可以对抛出异常进行争论，这只是一个例子。 返回状态、布尔值，无论你想要什么。

Answer 2

我同意 AviewAview 的观点，但只有在用户告知时才会抛出异常（如果他询问则不会）：

public Foo
{
  bool Validate(Baz bar)
  {
        if(!is_number(bar)) return false;
        return true;
  }

  AssignBar(Baz bar)
  {
        if (!Validate(bar)) throw numberexception();
  }
}

Tell:

try
{
  foo.AssignBar(bar);
}
catch(numberexception e)
{
  alert('Not a number!');
}

Ask:

if (foo.Validate(bar)
{
  foo.AssignBar(bar);
}
else
{
  alert('Not a number!');
}

所以，AssignBar 期望一个 VALID bar，如果不是，则抛出异常，但我们还提供了一个 Validate 方法，该方法不会不抛出异常。

Answer 3

我想知道这是否更多的是“关注点分离”而不是“告诉而不询问”的问题。 验证数据由谁负责？ 可以说，它是负责持久化的东西。

当然，有时验证多层数据很有用。 如果您的应用程序属于这种情况，那么我在“用户”层中公开验证逻辑没有问题。 但我仍然希望它在业务层。