自定义 Java Swing GUI 与 Netbeans 拖放编辑器答案

【问题标题】：Custom Java Swing GUI vs. Netbeans Drag n' Drop Editor自定义 Java Swing GUI 与 Netbeans 拖放编辑器
【发布时间】：2014-05-05 20:26:31
【问题描述】：

与使用 Netbeans Drag n Drop 编辑器相比，手动编写 Java Swing GUI 是否有任何优势？也许比如运行时？在我看来，编辑器会自动创建相当多的额外代码，但我不知道这是否会对加载视图的运行时产生很大影响。我目前使用编辑器的唯一原因是因为它使 GUI 构建快速而简单。但是，是否有一些只能通过手工编码才能完成而无法通过编辑器完成的事情？

还有更好的 GUI 框架吗？我看过 Java FX，但我真的很想要 Github 桌面软件所具有的那种效果。它看起来如此流畅和干净，几乎就像一个网络应用程序。虽然我确信他们是用 C++ 做到的。在我看来，Java 在图形方面并没有太多优势。我的一位朋友评论说，所有 Java 程序看起来都一样，到目前为止似乎是真的。

我知道有类似的帖子，但坦率地说，它们不是最近发布的，例如 2010 年发布的 Write gui programatically, or using an advanced gui editor (Java Swing)? 或同样在 2010 年发布的 Learning Java Swing (GUI builder or not?)。如果没有新内容，抱歉打扰您。

【问题讨论】：

标签： java swing user-interface netbeans

【解决方案1】：

手工编写 Java Swing GUI 比使用 Netbeans Drag n Drop 编辑器有什么优势吗？

有很多，但让我们从显而易见的开始......

不会将您锁定在单一的开发环境中。这意味着您的代码可以与可能未使用 Netbeans 的其他人共享。当您使用基于 Maven 的项目时，这一点尤其重要
鼓励您学习 API。您可以很好地了解 API 的实际工作原理，并学习大量技巧来制作流畅灵活的界面。
鼓励更大程度地分离责任。简单地将组件拖到表单上，这一切都很容易，这对封装或管理没有任何作用。通过将 UI 划分为责任区域，可以更轻松地管理组件之间的不同状态和关系。它还使代码通常更易于阅读，因为您无需不断丢弃与您要弄清楚的内容无关的内容。
更好的可扩展性。在最好的情况下扩展组件并不容易，但使用基于表单的组件几乎不可能（或者至少困难一个数量级）
Netbeans 表单编辑器代码...一团糟...

不要误会我的意思，我使用表单编辑器，但在我拿起表单编辑器之前，我已经手工编写 Swing GUI 的代码已有十年了。我喜欢用于布置最终屏幕的表单编辑器，并且倾向于在每一步都使用手工编码的 UI，可以说是把钉子钉在洞里。

简短的回答是 - 在您可以手工制作多级 GUI 之前，请远离表单设计者 - 恕我直言。

我知道有些人认为他们是很好的学习工具，我认为恰恰相反，我认为他们会让你养成懒惰和坏习惯，这会影响你未来所做的一切。

虽然开发环境不应该有所作为，但不是每个人都想使用 Netbeans，最好学会不用

还有更好的GUI框架吗？

这是一个见仁见智的问题。 Swing 通过使用look and feel 架构带来了蒙皮概念，它使您能够改变组件的外观和感觉。

JavaFX 通过使用 CSS 提供了类似的功能

Swing 也是高度可定制的，很容易进入组件的“绘制”级别，甚至可以根据需要生成自己的组件。

制作“流畅”用户界面的能力与工具包无关，而取决于开发人员。将字段和其他组件拖放到容器中很容易，但需要一个对底层 API 有很好理解的开发人员和一些真正看起来不错的人才才能使它看起来“光滑”。

漂亮并不总是等于实用。最好的 UI 是您无需考虑的，不会妨碍您并且可以正常工作的 UI。当您使用一个程序数小时、数天、数周时，您不会关注 UI 看起来有多漂亮，而是关注它如何让您完成想要的工作 - 恕我直言

【讨论】：

+1 再次成为 10 年伟大的程序员。但我能问一个问题吗？我的想法。 @MadProgrammer
如果我们通过 Handcode 编写所有代码意味着如果我们不使用 netbeans 那么您不认为会有复杂的事情吗？不适合你，因为我无法将自己与你进行比较，因为你经验丰富，但适合像我们这样更新鲜的人。
@Krishna 手工制作可以养成良好的习惯（恕我直言）。使用表单设计器“很容易”，很容易（我已经这样做了）简单地放置在组件和容器的层层之上，最终得到 10 个（如果不是 100 个）大部分不相关的组件......管理和维护突然变得异常复杂。手动编码通常意味着找到那些相关的元素并将它们放置在自己的上下文中，简单，因为这样更容易管理，进一步促进封装和责任分离......恕我直言
我已经尝试过一次不使用 netbeans 的操作，你觉得它很复杂，顺便说一句，你使用的是哪个编辑器？
我使用 Netbeans。现在，我倾向于将它用于概念验证而不是实际开发......有时隐藏复杂性并不是一件好事。当然，当您已经编写了几个星期的复杂 UI 代码时，您可能会有不同的想法，但这项繁重的工作可以帮助您学习如何制作 Swing、Swing...

【解决方案2】：

GUI 构建器无法通过手工编码完成的第一件事是：动态更改界面。

例如：

如果您想构建一个包含多个JTextFields 的表单，但您不确定构建 GUI 时会有多少个。该程序将需要动态填充JTextFields。这对于 GUI Builder 是不可能的。

此外，当您有复杂的界面时，GroupLayout 的大小调整行为可能会很麻烦且令人困惑。另一方面，当您编写复杂的界面时，手工编码的布局需要做很多工作（但至少它们的调整大小行为是可预测的）。

【讨论】：

我记得使用 Netbeans GUI 编辑器创建一个组件，该组件可以根据存储在 XML 中的规范创建一个 GUI ..它会在读取 XML 后在运行时生成 GUI . XML 基于 XScreenSaver 格式，GUI 是屏幕保护程序设置对话框。因此，对于“GUI 设计器无法在运行时生成 GUI”，我给出了明确的答复——“不，你错了”。
@AndrewThompson，好的，但是...... GUI 构建器的首要目标是帮助您更快、更轻松地创建 GUI，而不是手动编码它们。因此，如果您必须手动编写 XML 文件以在运行时生成 GUI，这不会首先破坏目的吗？也许明确的“不能”是不正确的，但“不适合”会更好？
'often' 通常胜过'always'，因为它解释了......非常罕见的情况，人们正是在这种情况下使用它。至于你更一般的评论。我不相信通过 XML 指定 GUI 的情况（尽管我承认在某些情况下编写它会更简单）。 XScreenSaver 的情况被我们试图保持兼容性的基于 C++ 的 API 的存在有效地“锁定”了，顺便说一句。如果不是这种情况，GUI 是否会基于 XML 是有争议的（对于这种简单类型的 UI，我会投“是”）。

【解决方案3】：

应该使用经典的 GUI 构建器来制作 GUI 原型。一旦你确切地知道你想要什么，你应该摆脱它并清理代码（分解它，记录它，......总之让它简单易读）。

我的一个朋友评论说，所有的 Java 程序看起来都一样，到目前为止，这似乎是真的。

并非绝对正确：JavaFX 外观可通过 css 自定义。 Swing 也可以通过 LAF 系统或通过覆盖 paint* 方法完全自定义（我承认更耗时）。

如果您想寻找没有生成代码缺点的简单方法，我建议您查看ReflectionUI：易于外观定制（这不是唯一的好处）：。

【讨论】：