我通常使用ASP.net Web表单进行GUI，也许是最“有状态”的技术之一。但它适用于任何拥有国家的技术。有时形式是棘手且复杂的，具有> 30个元素和＆gt;每个元素的3个状态。设计这种形式的直观方式通常可以达到90％。其他10％通常会找到测试人员或最终用户：）。
我认为问题是我们应该想象同一个对象上的很多场景，这比独立操作的结果要难得多。
从函数式编程课程我知道最好的方法不是使用状态管理，而是使用纯函数和变量值传递以及所有这些东西，这些都是非常正式的。有时候，我们无法避免它。
您是否使用任何数学形式和方法来对复杂对象进行状态管理？不像Haskell中的monads，但它可以用于更传统的业务应用程序和语言 - Java，C＃，C ++。
可能不是图灵完整的形式主义，但99％也会很好：）。
对不起，如果只是另一个风滚草问题：）
答案 0 :(得分：1)
使用消息传递作为抽象。优点：
答案 1 :(得分：0)
可能不是图灵完整的形式主义，但99％也会很好：）。
很抱歉，我宁愿提供NP-complete解决方案：）
我的快速回答是Test-Driven Approach。但请进一步阅读。
我认为我们应该解决这个问题 想象一下同样的很多场景 对象，这比一个难得多 独立运作的后果。
在这种情况下，分解（不仅在computer science意义上，而且在mathematical意义上）非常有用。 您可以在许多更简单的中分解复杂场景，这反过来可能仍然很复杂，可以进一步分解。
作为这样一个过程的结果，你应该得到一些简单的函数（任务），这些函数大多与每个函数无关。 这非常重要，因为那样你可以UNIT TEST这些简单的场景。 此外，遵循test-first 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（更确切地说是其部分）正常工作正确。此外，您可以为场景A编写另外3个测试，它们将所有已分解的部分组合在一起 - 这种测试经常（但并非总是如此！）可以被视为{{3 }}
然后让我们假设在方案A中发现了一个错误。您不确定它属于哪个部分，但您怀疑它与A1-2或A3有关。因此，为每个场景再编写 重现错误（编写一个无法满足您期望的测试）。在您复制了错误后，您修复它并使所有测试通过。
现在您还有2个正确工作系统的证明，确保所有以前的功能都以相同的方式工作。
这种方法有两个主要的主要问题IMO。
此过程称为测试驱动开发。我发现它是发展过程中最接近的“形式化”，在科学与现实世界之间发挥了很好的作用。
所以我在这里并没有真正谈论状态，而是行为并证明它可以正常工作。
从个人经验来看，我应该提到ASP.NET WebForm在技术上非常难以测试。 为了克服这个问题，我建议 Integration testing 。
与WebForms相反， ASP.NET MVC更容易进行测试。 但是，你应该有一组所谓的“服务”（我们的场景）和（单元）分别测试它们，然后测试接近集成测试的环境中的UI集成。