如果不断的界面反模式是这样的犯罪,为什么Swing会这样做呢？

Question

我正在制作一个swing应用程序,并意识到我有一些需要访问同一组常量的类.我不能让自己宣布一个人是他们的主要持有人并将他们全部放在那里并让其他人参考它; 我想,嘿,我只是让它们都从一些常见的地方继承,但是Java不会做多重继承,但我可以把无限接口放在东西上.所以我想把它们全部转移到一个界面中(这是真的,我自然而然地没有进行任何研究).

我后来才知道这是异端邪说."事实上,它有一个名称,它有一个名称:恒定接口反模式" - 如此处所讨论的(以及替代解决方案(我选择使用)).

我一直很好,直到我查看的源代码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)中被大量使用？

Answer 1

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

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

虽然可能不是很好的风格,但这并不是那么不寻常,如果我们将JDialog改为使用静态导入而不是实现,那么会破坏WindowConstants.