如果常量接口反模式就是这么犯罪，为什么 Swing 会这样做呢？答案

【问题标题】：If the constant interface anti-pattern is such a crime, why does Swing do it?如果常量接口反模式就是这么犯罪，为什么 Swing 会这样做呢？
【发布时间】：2023-03-05 17:54:01
【问题描述】：

我正在制作一个 Swing 应用程序，并意识到我有几个类需要访问同一组常量。我不能让自己宣布其中一个是它们的主要持有者并将它们全部放在那里并让其他人参考它；我想，嘿，我会让它们都从某个共同的地方继承，但 Java 不做多重继承，但我可以在事物上放置无限接口。所以我想到了将它们全部转储到一个界面中的想法（这是真的，这只是我自然而然地想到的，没有做任何研究）。

我后来才知道这是异端。 “事实上，这是一个糟糕的主意，它有一个名字：常量接口反模式” - as discussed here（以及一个替代解决方案（我选择采用））。

在我查看 JDialog 和 JFrame 的源代码之前，我觉得这很好，读起来是这样的：

public class JDialog extends Dialog implements WindowConstants,
                                               Accessible,
                                               RootPaneContainer,
                               TransferHandler.HasGetTransferHandler
{
...

和

public class JFrame extends Frame implements WindowConstants,
                                             Accessible,
                                             RootPaneContainer,
                             TransferHandler.HasGetTransferHandler
{
...

也许只有我一个人，但我确实看到了一个不变的界面。更有趣的是 JDialog 中的作者声明之一，即 James Gosling。语言之父允许这个所谓的错误在他的监视下？

（另一个值得注意的例子 - SwingConstans）

如果常量接口反模式是个坏主意，那么为什么它在该语言最著名的包之一（即 Swing）中被如此广泛地使用？

【问题讨论】：

我真的很讨厌摆动常数。真的真的真的。
这些类早于 Java 枚举的存在。这可能就是原因。
出于好奇，为什么不静态导入常量？
你问我为什么不这样做（如果你仔细阅读，我说我会这样做）或者为什么 Swing 不这样做？如果是后者，我支持你的问题。
Swing 没有，因为在编写 Swing 时，java 中没有 static 导入。

标签： java swing interface constants anti-patterns

【解决方案1】：

在 java 5 之前没有更好的使用static import 的解决方案。到目前为止，滥用接口导入常量被认为是可以接受的，因为没有更好的选择。一旦你决定 JDialog 实现 WindowConstants （并在文档中断言），你不能在不破坏向后兼容性的情况下撤消它。示例：

JDialog d = new JDialog();
int flag = d.DISPOSE_ON_CLOSE;

虽然可能不是很好的风格，但这并不罕见，如果我们将 JDialog 更改为使用静态导入而不是实现 WindowConstants，这将会中断。

【讨论】：