【发布时间】：2011-01-21 04:39:15
【问题描述】：
是否有解释摇摆 GUI 设计的资源？比如最佳实践等。
【问题讨论】：
标签： java user-interface swing
【发布时间】：2011-01-21 04:39:15
【问题描述】：
不再完全遵循设计指南，因为 Swing 可以在许多不同的平台上工作。 Sun 很久以前写过一些东西，并且从未更改过它们，所以如果您认为它会有所帮助，我会说阅读它。这里有一些关于swing开发的实用知识。
- 永远不要使用 GridBagLayout。抓取表格布局。它从根本上简化了 Swing UI 的布局。 GridBagLayout 是魔鬼。
- 不要为了获得正确的布局而过度嵌入组件（即嵌入的 BoxLayout 等）。有关如何执行此操作，请参见第 1 点。屏幕上的组件存在性能问题。
- 按照 MVC 行分隔您的程序。 Swing 具有视图和模型分离，但在大型程序中，视图（即 Swing 组件的子类）变成了伪视图/控制器，只会使重用和维护变得复杂。它很快变成了意大利面条代码。打破习惯并创建一个不扩展 Swing 的 Controller 类。模型也是如此（没有摆动）。控制器实例化高级视图类，并将其自身连接为视图的侦听器。
- 仅使用简单面板简化弹出对话框。不要继承 JDialog。创建一个可重用的对话框类，该类包装了一个面板，可以使用 JOptionPane 之类的东西。您的面板不会仅绑定到对话框，并且可以重复使用。以这种方式工作非常容易。
- 避免动作监听器/命令。这是旧垃圾，不是很可重用。使用 AbstractAction （匿名类是你的选择，我对它们没有问题）。 AbstractAction 封装了文本、图标、助记符、加速器，可重用在按钮、弹出窗口、菜单、切换启用/禁用状态的句柄，可以在多个组件之间共享，它也是 InputMap/ActionMaps 将键盘敲击映射到动作的基础。 ActionMap 为您提供重用的强大功能。
- 最好必须查看发送到控制器的事件。我不是在谈论鼠标/键盘垃圾，而是高级事件。像 NewUserEvent、AddUserEvent、DeleteUserEvent 等。让您的控制器监听这些高级业务事件。这将通过将视图的关注点（我应该使用表、列表、树还是其他东西？）与应用程序的流程分开来促进封装。控制器不关心用户是否点击了按钮、菜单或复选框。
- 事件不仅仅针对控制器。 Swing 是事件编程。您的模型将在 SwingThread 之外或在后台执行操作。将事件分派回控制器是一种非常简单的方法，可以让它响应模型层中发生的事情，这些事情可能正在使用线程来完成工作。
- 了解 Swing 的线程规则！您会惊讶地发现很少有人真正了解 Swing 是单线程的，以及这对多线程应用程序意味着什么。
- 了解 SwingUtilities.invokeLater() 的作用。
- 永远不要使用 SwingUtilities.invokeAndWait()。你这样做是错的。不要尝试在事件编程中编写同步代码。 （* 在某些极端情况下 invokeAndWait() 是可以接受的，但 99% 的情况下您不需要 invokeAndWait() ）。
- 如果您要从头开始一个新项目，请跳过 Swing。它老了，一切都结束了。 Sun 从来没有像对待服务器那样真正关心客户端。 Swing 一直维护得很差，自从它第一次编写以来并没有太大的进步。 JavaFX 还没有出现，并且遭受了许多 Swing 的罪恶。我会说看看Apache Pivot。许多新想法和更好的设计以及活跃的社区。li>
【讨论】：
-
很多优点。感谢您的回答 Apache Pivot 看起来不错。但是，我不喜欢为 GUI 使用 XML 的想法。看起来很混乱。
-
XML 仅用于布局。这就是 Flex 和 Silverlight 采用的方法。想一想：在 Swing 中，我们将 Java 包裹在我们的布局中，这使得构建 WYSWYG 编辑器变得困难。那里有一些，但获得 Visual Studio 十年前的资源文件的速度很慢。因此，您仍然使用 Java 编写代码，但您使用 XML 布局 UI。而且由于布局是在 XML 中的，因此您可能会使用可视化编辑器，因为 XML 比 Java 更容易解析。它实际上将您的代码与视图分开。
-
好点，但我不得不不同意一些。 1. GridBagLayout 不是魔鬼。魔鬼在不必要时使用。这是复杂的布局，真的，但它运作良好。 2. AbstractAction 很棒——但它用于 ui 中的每个动作组件都会很快导致无法维护的混乱。所以我推荐这两种方法的结合。 AbstractAction 用于将被重用的代码，ActionListener 用于本地使用。
-
这样看GridBagLayout。既然有更好的工具，为什么还要使用工具？ TableLayout 可以用更少的代码完成 GridBagLayout 可以做的所有事情。您可以使用 GridBag 将代码页转换为使用 TableLayout 的 5 行代码。试一试，我向你保证，你再也不会希望 GridBagLayout 出现在任何人身上。在使用 TableLayout 之后，我还没有遇到过更喜欢 GridBagLayout 而不是 TableLayout 的 Swing 开发人员。
-
Flex 和 Silverlight 使用 XML 的事实并不意味着它很好！我也不喜欢用 XML 来布局 GUI。有很多 Swing LayoutManager 可以在纯 Java 中提供良好的布局。检查 DesignGridLayout 和 MigLayout（还有其他）。
我已经写了一个推荐列表here。
【讨论】：
在较大的摇摆项目中，我会像这样对应用程序进行分区：
每个 GUI 元素都有一个类，如 JPanel、JDialog 等。
为每个屏幕使用单独的包，尤其是在您必须实现自定义 TableModel 或其他复杂数据结构时
不要使用匿名类和内部类，而是实现一个 ActionListener 并在其中检查 ActionEvent.getActionCommand()。
编辑：如果您更想寻找教程或介绍，您可以开始 here
【讨论】：
-
+1 表示没有匿名内部类——这些和闭包是 GUI 中代码重用的死亡。
-
同意，但问题似乎与 UI 人体工程学和用户体验有关。
-
@Pascal Thivent 谢谢，我们应该推荐 swt？
-
看看 Apache Pivot 而不是 SWT。 Apache Pivot 作为 UI 工具包做了一些非常好的事情。
也许不是你想要的，但看看Java Look and Feel Design Guidelines不会有什么坏处
【讨论】：
您可以在Professional Java JDK6 Edition 的第 4 章中找到一些最佳实践
【讨论】：
我也有一些指导方针：
1) 使用 Maven 并将您的应用程序分成模块（视图、控制器、服务、持久性、实用程序、模型）。确保只将 Swing 组件和依赖项放在视图包中，因此如果有一天您想更改视图框架，您可以只重新实现视图模块，但您可以保留业务逻辑、控制器等……原封不动。
2) 使用 GridBagLayout，因为它非常灵活且最可配置
3) 使用 SwingTemplate（如果你愿意，我可以给你一个例子）
4) 创建一个 SwingFactory 来创建组件，这样您就可以减少代码行数，因为 JFrame 或者打算成为非常大的类...
5) 让视图（JFrame、JDialog 等）对控制器有依赖。仅在 JFrame 上进行验证输入，然后将参数传递给控制器。他们将决定触发哪些业务逻辑（服务、处理器等）。
6) 使用大量枚举
7) 始终考虑您的应用程序可以如何更改或如何维护。因此，始终针对接口或抽象类使用代码。 （思考抽象）
8) 在您的应用程序中使用设计模式，因为它们为您的代码提供了舒适性和可维护性。例如，制作你所有的控制器、服务、dao 的单例类。制作工厂（swingfactory，...），这样您就必须一遍又一遍地编写更少的代码......使用观察者，以便可以自动处理操作。
9) 测试您的应用程序：选择：TDD（测试驱动设计）或 DDT（设计驱动测试）
10) 永远不要在 JFrames 上放置任何业务逻辑，因为它很丑，而且它的模型-视图-控制器设计也不是很好。 JFrame 并不关心数据的处理方式。
希望对您有所帮助。
【讨论】：