user-interface - 任何数学方法来管理复杂对象的状态？

Question

我通常为 GUI 使用 ASP.net Web 表单，这可能是最“有状态”的技术之一。但它适用于任何具有状态的技术。有时表单很复杂，有超过 30 个元素，每个元素有超过 3 个状态。设计这种形式的直观方式通常适用于 90%。其他 10% 通常会找到测试人员或最终用户:)。

我看到的问题是我们应该在同一个对象上想象很多场景，这比独立操作的结果要困难得多。

从函数式编程课程中，我知道最好的方法是不使用状态管理，而是使用纯函数和按值传递的变量以及所有这些非常形式化的东西。有时，我们无法避免。

您是否使用任何数学形式和方法来管理复杂对象的状态？不像 Haskell 中的 monad，但它可以用于更传统的业务应用程序和语言——Java、C#、C++。

这可能不是图灵完备的形式主义，但 99% 也会很棒:)。

对不起，如果这只是另一个风滚草问题:)

score 1 · Accepted Answer

使用消息传递作为抽象。好处：

复杂状态的困难在于复杂的交互，这在典型的 GUI 等并发系统中尤其棘手。消息传递通过消除共享状态，阻止了一个进程中状态的复杂性具有传染性。
消息传递并发有很好的基础模型：例如，Actor 模型、CSP，它们都影响了 Erlang。
它与函数式编程很好地集成：再次查看 Erlang。 Peter van Roy 的书 *Concepts, Techniques, and Models of Computer Programming是一本极好的文本，它展示了编程语言的基本要素，例如纯函数和消息传递，以及它们如何组合。该文本可作为免费 PDF 获得。

score 0 · Accepted Answer

这可能不是图灵完备的形式主义，但 99% 也会很棒:)。

对不起，但我宁愿提供 NP-complete 解决方案:)

我的快速回答是Test-Driven Approach。但请进一步阅读以了解更多信息。

我看到的问题是我们应该在同一个对象上想象很多场景，这比独立操作的结果要困难得多。

在这种情况下，分解（不仅在计算机科学意义上，而且在数学上也是如此）非常有用。您将复杂的场景分解为许多更简单的场景，而这些场景本身仍然可以很复杂，并且可以进一步分解。

作为这样一个过程的结果，您应该最终得到许多简单的功能（任务），这些功能（任务）大多独立于每个功能。这非常重要，因为您可以对这些简单的场景进行单元测试。此外，遵循测试优先的方法更容易更好，这种方法允许在开发过程的一开始就看到分解。

您是否使用任何数学形式和方法来管理复杂对象的状态？

继续我说的，对我来说最重要的是做好分解，这样我就可以保证质量，并且能够以自动化的方式轻松重现错误。

给你一个抽象的例子：

你有一个复杂的场景 A。您总是需要为每个场景编写至少 3 个测试：正确输入、错误输入和极端情况。

开始编写第一个测试（正确输入）我意识到测试变得太复杂了。

结果，我将场景分解 A为不太复杂A1的 , A2, A3. 然后我再次开始为它们中的每一个编写测试（我最终应该至少有 3*3=9 个测试）。

我意识到这A1 仍然太复杂而无法测试，所以我再次将其分解为A1-1, A1-2。现在我有 4 种不同的场景（A1-2、A1-2、A2、A3）和 3*4=12 潜在测试。我继续编写测试。

在我完成之后。我开始实施，所以我所有的测试都通过了。之后，您有 12 个证明该场景A（更准确地说是其部分）正常工作。此外，您可能会为结合其所有分解部分的场景编写另外 3 个测试A- 这种测试通常（但不总是！）可以被视为集成测试。

然后让我们假设在场景中发现了一个错误A。您不确定它属于哪个部分，但您怀疑它与A1-2or相关A3。因此，您为每个场景再编写 2 个测试来重现错误（编写这样一个未能满足您期望的测试）。重现错误后，您修复它并使所有测试通过。

现在，您还有 2 个正确工作系统的证明，可确保所有以前的功能都以相同的方式工作。

这种方法IMO有两个主要问题。

这个过程称为测试驱动开发。我发现它是最接近科学与现实世界之间的发展过程的“形式化”。

所以我在这里并没有真正谈论状态，而是谈论行为并证明它可以正常工作。

根据个人经验，我应该提到 ASP.NET WebForm 在技术上很难测试。为了克服这个问题，我建议对 ASP.NET WebForms 应用 MVP 模式。

与 WebForms 相比，ASP.NET MVC 更容易测试。但是，您仍然应该有一组所谓的“服务”（我们的场景）和（单元）分别测试它们，然后在接近集成测试的环境中测试 UI 集成。

2 回答 2