Botframework Bot框架v4中的WaterwallStep设计与坚实原则

从botframeworkv3开始，研究文档/示例之后，我仍然不理解为什么v4中的waterwallstep对话框处理是以这种方式实现的

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

给定一个包含3个步骤PromptName、PromptAge和PromptLocation的瀑布，我看到以下内容：

• 方法命名：如果出现第二次和第三次提示，方法命名将变得不清晰。当然，我们会使用AskForAge（）或AskForLocation（），但由于下一点，这是误导性的
• 可靠原则：当我们在每一步中做两件事时，是否违反了“单一责任原则”？存储前一个响应，同时在同一个方法中请求下一个响应，这最终导致方法名，如AskForLocationAndStoreAge（）
• 代码重复：由于每个步骤都假设来自前一步骤的具体输入，因此无法轻松重用，也无法更改顺序。即使是最简单的样本也很难读取

---

我正在寻找一些关于为什么选择这样的设计或者我在概念中遗漏了什么的澄清

这个问题似乎主要基于观点，因此我不知道它是否适合堆栈溢出。事实证明，有一个很好的地方可以问这些问题，那就是。我还是会尝试回答这个问题

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

这与机器人对话的工作方式有关。在其最基本的形式中，没有任何对话框、状态或任何东西，bot通过回答问题或以其他方式响应用户的消息来工作。也就是说，机器人程序的整个生命周期是接收一条消息，对其进行处理，并在接收到的消息在某种意义上仍处于“活动”状态时提供响应。然后，bot从用户处接收到的每一条后续消息都会以与从未接收到第一条消息相同的方式进行处理，就像该消息是由一个全新的程序实例处理的，该程序没有以前消息的内存

为了让机器人对话感觉更加连续，需要机器人状态和对话框。通过对话框，特别是提示对话框，机器人现在能够向用户提问，而不仅仅是回答用户提出的问题。为了做到这一点，bot需要将有关对话的信息存储在某个地方，以便当收到来自用户的下一条消息时，bot程序的新“实例”将知道来自用户的消息应该被解释为对该程序的前一实例所问问题的响应。这就像给下一班工作的人留下一张便条，让他们知道上一班发生的事情，他们需要跟进

了解了所有这些，由于对话和对话的性质，在瀑布中处理上一步的结果似乎很自然。在包含提示的瀑布式对话框中，bot将接收与bot发送的最后一条消息相关的消息。因此，它需要在下一步中处理上一步的结果。它还需要对消息做出响应，在瀑布中，这通常意味着要问另一个问题

当我们在每一步中做两件事时，是否违反了“单一责任原则”？存储前一个响应，同时在同一个方法中请求下一个响应，这最终导致方法名，如AskForLocationAndStoreAge（）

据我所知，是指类而不是方法。如果它确实引用了方法，那么在这种情况下，该原则很可能被违反或以某种方式扭曲。然而，它不一定是。您可以自由地使用多个方法来处理每个步骤，甚至可以使用多个步骤来处理每个消息。如果需要，您的瀑布可以包含一个步骤，该步骤处理前一个提示的结果，然后继续执行下一个步骤，生成新的提示

由于每个步骤都假定来自其前一步骤的具体输入，因此无法轻松重用，也无法更改顺序。即使是最简单的样本也很难读取

最终，您可以控制输入的验证/解释方式，使其尽可能具体。对话框或瀑布步骤的可重用性与您想要做的不同事情的相似程度有关，与编程的任何领域一样。如果样本很难阅读，我建议对这些样本提出问题。当然，在适当的回购协议中，您仍然可以提出SDK本身的设计问题，但是请考虑对您认为应该采用的方式提出建议。