我正在帮助为客户端构建一个GWT应用程序，并重写大部分内容，使其工作得更好、代码更短、速度更快等。然而，在我开发过的所有GUI应用程序中（实际上并没有那么多），都有一个灵活的点，即您只需要放入大量规则，并将逻辑从侦听器转移到一些通用的中介器。然后有些时候，这可能会变得一团糟，所以你需要在听众身上做任何微小的想法。
让我们举一个例子：
- 具有10-20个字段的表单
- 两个专用无线电控制其他字段状态的一半（启用、验证、输入限制）
- 三个排他性的无线电控制再次控制几乎相同的字段，但方式不同（影响计算，启用）；它们也受上述控制
- 根据先前的选择和一些实时数据对象，动态验证4个左右的数字字段；它们可以有上限/下限，可以启用/禁用
- 一个下拉框控制接下来的6个左右的控件-显示/隐藏它们，修改验证器
- 一些复选框（由上面的组合框显示）激活一些输入字段，并确定它们的验证算法
虽然一切都在运行，没有已知的错误，但有几个编码问题真的困扰着我：
- 代码在监听器和一些中介方法之间传播
- 加载带有一些预设值的表单会带来自身的挑战：比如可能可用或不可用的数据对象，可能会改变其状态和随后字段行为的数据对象
- 有些字段设置了默认值，这不应该被自动填充所覆盖，但如果数据对象还不存在，那么当稍后数据对象可用时，最终需要填充它们
- 如果任何字段未经验证，则无法提交表单
我的方法：
- 识别哪些字段共享一个通用afair并将代码移动到一个位置
- 每个无线电组在其无线电之间共享一个侦听器实现
- 默认的表单填充被推迟到实时数据可用（尽可能多），因此它会被调用多次
- 每个操作都有一个对通用验证器方法的调用
- 验证器运行表单中的所有字段，调用它们的验证器（突出显示所有错误）并返回一个布尔值
- 每次相关的按键或鼠标操作，数据更改将在上次调用后250ms后延迟调用；这意味着第一个调用只是将验证器作为延迟操作，随后的调用重置计时器
好吧，深入了解更多细节没有任何意义，但我更担心的是，视觉操作（启用）、数据操作（设置表单字段值）、字段监听器、检索表单值和实时数据监听器之间没有明确的分隔。
什么是一个好的方法/模式（也许下次）来确保MVC分离并更好地进行维护？我知道这不是一个典型的问题，但我已经阅读了我能拿到的所有文档，仍然没有找到一些有用的答案。
比起MVC，我更倾向于MVP。这显然是谷歌想要走的路，所以采用它可能意味着你能够顺应潮流，而不是对抗当前的。
这对你有什么影响？好吧，我相信你应该接受一个更整洁的实现可能涉及更多的代码：而不是你希望的"更短的代码"。但是，如果它是逻辑结构、高效的代码，谷歌编译器应该能够在编译器优化阶段修剪掉很多代码。
因此，将尽可能多的逻辑移动到模型层中。彻底测试这一点，并验证页面重置/整理的级别是否正确（所有这些都可以用普通的JUnit完成，而不需要任何UI）。接下来，使用演示者（活动）将视图与模型联系起来：处理交互、填充字段等。
您可以将一个巨大的类划分为不同的类，而不需要将GUI划分为不同JPanel。所有面板都是在扩展JPanel的不同类中实现的。我想这会对你有所帮助。