java - 如果常量接口(interface)反模式是一种犯罪行为，那么 Swing 为什么要这样做呢？

Question

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

后来才知道这是异端。 “事实上，它有一个名字:常量接口(interface)反模式” - 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)

如果常量接口(interface)反模式是一个糟糕的主意，那么为什么它在该语言最著名的包之一(即 swing)中如此大量使用？

Answer 1

在 Java 5 之前还没有使用 static import 的更好解决方案。到目前为止，滥用接口(interface)导入常量被认为是可以接受的，因为没有更好的选择。一旦您确定 JDialog 实现了 WindowConstants(并在文档中声明了这一点)，您就无法在不破坏向后兼容性的情况下撤消它。示例:

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

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