用于用户操作验证的Java Swing GUI设计技术（MVC-FSM）

我已经使用Swing实现了GUI，并且总是尽可能地遵循MVC模式。
不过，我想知道MVC是否不是这个难题的唯一部分。
GUI设计中是否也使用FSM？
我从未在GUI中使用过FSM，我的方法是：在操作时，调用控制器的相应方法，以更新模型结束，最后更新视图。
通常，当用户的操作触发请求时，我会使用一些简单的检查来确保用户能够执行此类操作：是否启用了特定组件？或者这种标签是可见的？等等
到目前为止，这似乎是可行的，但我必须承认我是“幸运的”，不必构建太复杂或复杂的GUI。
我以前构建过FSM（在不同类型的应用程序中，主要是在C++中），我开始怀疑GUI中的FSM是否实际用作模式和我的方法，即检查ActionListeners代码，根据用户看到的内容以及启用或禁用的组件等来确定用户是否应该看到一些错误消息，而不是能够执行特定的操作，例如按钮承诺对成熟的GUI应用程序来说实际上是个坏主意。
那么，除了如何实现MVC之外，在开始设计GUI时，您在设计中是否适合/关联FSM？
更新：
在回顾了Dhruv Gairola在评论中的文章后，我仍然对此感到困惑。
本文提到构建一个FSM，虽然它实际上绑定到计算器实现，这意味着即使计算器是在没有GUI但通过命令行获取用户输入的情况下实现的，仍然需要FSM。
我仍然不确定FSMs在每个时间点验证用户的操作是流行的还是有效的设计。
这似乎太费劲了，需要完全提前设计GUI，并根据特定状态将所有可能的用户操作映射到特定结果。
鉴于没有任何评论，只有一个回复，我倾向于认为可能FSM（用于验证用户对控件的操作）实际上没有使用

欢迎对此提供任何意见。

---

谢谢。

让我们这样说吧-设计模式主要是对不同设计原则的阐述，例如，封装变化的内容、编程到接口，而不是实现等。因此，您不必使用模式或任何东西，基本上确保您的编程方式符合良好的设计原则。如果在特定设计中使用FSM是有意义的，我建议您使用它。通常鼓励使用模式，以便其他程序员能够理解您的逻辑，并根据他们对模式的了解轻松地对其进行扩展。没有硬性规定说你必须使用MVC，你必须使用诸如此类的东西。。结论：只要你正在应用的模式符合良好的设计原则（或者即使你没有使用特定的模式），就要确保它设计得很好，并且足够好，让其他人能够轻松地扩展和理解它。这是我的两分钱。

好吧，你说得有道理，但有一种情况是，特定的设计模式是公认的唯一出路。例如，UI桌面/web应用程序中的MVC。我不认为有人会认为UI中的MVC是占主导地位的方法。所以我想知道，用户在特定情况下能做什么或不能做什么的验证，是否通常与FSMwell相关，我见过FSM像中一样被使用，但我理解您的担忧。也许会有一些启示。嗯，好问题。这是一篇很棒的文章！我真的很喜欢GUI编程，FSM对我来说就像一块丢失的东西！我总是有一种模糊的感觉，就是在这整个摇摆、BeansBinding、MVC和验证人群中缺少了一些东西。所有这些都涉及GUI编程的非常重要的方面，但FSM使其更加完整。谢谢你告诉我这件事！在阅读了您评论中的文章之后，我仍然对此感到困惑。文章提到构建一个FSM，虽然它实际上绑定到计算器实现，这意味着即使计算器是在没有GUI但通过命令行获得用户输入的情况下实现的，仍然需要FSM。