如果持续的接口反模式是一种犯罪行为，那么 Swing 为什么要这样做呢？

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

后来我才知道这是异端邪说。 “事实上，这是一个糟糕的主意，以至于有一个名字：常量接口反模式”-正如这里所讨论的 http://docs.oracle.com/javase/1.5.0/docs/guide/language/static-import.html（以及替代解决方案（我选择采用））。

我对此很满意，直到我查看了源代码JDialog and JFrame，其内容如下：

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

and

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

也许只有我这么认为，但我确实看到了一个恒定的界面。更有趣的是 JDialog 中的作者声明之一，即 James Gosling。语言之父在他的任期内允许这个所谓的错误？

（另一个值得注意的例子 -摇摆常数 http://docs.oracle.com/javase/7/docs/api/javax/swing/SwingConstants.html)

如果恒定接口反模式是一个坏主意，那么为什么它在该语言最著名的包之一（即 swing）中如此大量使用？

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

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

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