Bot Framework v4中的WaterfallStep设计与SOLID原理

时间:2018-12-30 22:55:59

标签: botframework

从Bot Framework v3迁移并研究了文档/示例之后,我仍然不明白为什么以这种方式实现v4中的WaterfallStep对话框处理。

为什么选择在瀑布中处理上一步的结果

给出一个包含3个步骤的瀑布PromptName,PromptAge和PromptLocation,我看到以下内容:

  • 方法命名::在第二和第三提示下,方法命名变得不清楚。当然,我们会做AskForAge()或AskForLocation(),但这会引起误解,因为下一点。
  • SOLID委托人:因为我们在每一步中都做两件事,所以不违反“单一责任委托人”吗?在使用相同方法请求下一个响应的同时存储上一个响应,最终导致诸如AskForLocationAndStoreAge()之类的方法名称
  • 代码重复:由于每个步骤均假定其上一步的具体输入,因此无法轻松重用它,也无法更改顺序。即使是最简单的样本也很难阅读。

我正在寻找有关为何选择这种设计方式或我在概念中遗漏了什么的澄清。

1 个答案:

答案 0 :(得分:2)

这个问题似乎很大程度上是基于观点的,因此我不知道它适合于Stack Overflow。事实证明,实际上是一个提出此类问题的好地方,这就是BotBuilder GitHub repo。我将尝试同样的答案。

  

为什么选择在瀑布内处理下一步的上一步结果

这与漫游器对话的工作方式有关。机器人以最基本的形式,没有任何对话框,状态或任何内容,可以通过回答问题或以其他方式响应用户的消息来工作。也就是说,机器人程序的整个生命周期是接收一条消息,对其进行处理并提供响应,而在某种意义上,它仍然收到“活动”的消息。然后,僵尸程序从用户收到的每条后续消息都将按照从未收到第一条消息的相同方式进行处理,就像该消息正在由程序的全新实例处理,而没有存储先前的消息一样。

要使漫游器对话更加连续,就需要漫游器状态和对话。有了对话框,特别是提示对话框,机器人现在可以向用户提问,而不仅仅是回答用户提出的问题。为此,机器人程序需要将有关会话的信息存储在某处,以便当从用户处接收到下一条消息时,机器人程序的新“实例”将知道来自用户的消息应被解释为响应。该程序的先前实例提出的问题。这就像给下一个班次的工作人员留下一个笔记,让他们知道上一个班次期间需要跟进的事情。

知道了所有这些之后,由于对话和对话的性质,在瀑布内处理下一步的上一步的结果似乎很自然。在包含提示的瀑布对话框中,机器人将接收与机器人最后发送的消息有关的消息。因此,它需要在下一步中处理上一步的结果。它还需要响应消息,并且在瀑布中通常意味着要问另一个问题。

  

在每个步骤中做两件事时,是否违反了“单一责任主体”?在使用相同的方法要求下一个响应的同时存储上一个响应,最终导致方法名称如AskForLocationAndStoreAge()

据我了解,single responsibility principle是指类而不是方法。如果确实提到了方法,那么在这种情况下很可能会违反或改变该原则。但是,不一定如此。您可以自由地使用多种方法来处理每个步骤,甚至可以采取多种步骤来处理每个消息。如果需要,您的瀑布可以包含一个处理上一个提示结果的步骤,然后继续进行下一步以生成一个新提示。

  

由于每个步骤均假定其上一步的具体输入,因此无法轻松重用它,也无法更改顺序。即使是最简单的样本也很难阅读。

您最终可以控制如何验证/解释输入,以便可以根据需要进行具体设置。对话框或瀑布步骤的可重用性与您想要做的不同事情的相似程度(与编程的任何领域相同)有关。如果样本难以阅读,我建议对这些样本提出问题。当然,您仍然可以在适当的存储库中对SDK本身的设计提出问题,但是请务必考虑就您认为应该采用的方式提出建议。