如果不断的界面反模式是这样的犯罪,为什么Swing会这样做呢? [英] If the constant interface anti-pattern is such a crime, why does Swing do it?

查看:212
本文介绍了如果不断的界面反模式是这样的犯罪,为什么Swing会这样做呢?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I was making a swing application, and realized I had a handful of classes that needed access to the same set of constants. I couldnt bring myself to declare one the primary holder of them and place them all in there and have the others reference it; I thought, hey, I'll just have them all inherit from some common place, but Java doesnt do multiple inheritence, BUT I can put infinity interfaces on things. So the idea came to me to dump them all into an interface (it's true, it just naturally occurred to me without doing any research).

我后来才知道这是异端邪说。 事实上,它有一个名字,它有一个名称:Constant Interface Antipattern - 正如这里讨论的那样(以及另一种解决方案(我选择使用))。

I later learned that this is heresy. "In fact, it's such a bad idea that there's a name for it: the Constant Interface Antipattern" - as discussed here (along with an alternate solution (which I opted to employ)).

我对此很满意,直到我正在查看 JDialog JFrame 的源代码,这样读取:

I was just fine with this until I was looking at the source code for JDialog and JFrame, which read thusly:

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。语言的父亲在他的手表上允许这个所谓的错误?

Maybe it's just me, but I sure see a constant interface in there. Even more interesting was one of the author declarations in JDialog, i.e. James Gosling. The father of the language allowed this alleged mistake on his watch?

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

(Another notable example - SwingConstans)

如果常量接口反模式是个坏主意,那为什么呢它是如此大量使用在该语言最着名的一个包(即摆动)?

If the constant interface antipattern is such a bad idea, then why is it so heavily employed in one of the most famous packages of the language (i.e. swing)?

推荐答案

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

The better solution of using static import was not available before java 5. Up to this point, abusing interfaces to import constants was considered acceptable because there was no better alternative. Once you have decided that JDialog implements WindowConstants (and asserted this in the docs), you cannot undo it without breaking backwards compatibility. Example:

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

虽然可能不是很好的款式,但这并不是那么不寻常,如果我们要改用JDialog就会破坏静态导入而不是实现 WindowConstants

While probably not good style, this is not so unusual and would break if we would change JDialog to use static imports instead of implementing WindowConstants.

这篇关于如果不断的界面反模式是这样的犯罪,为什么Swing会这样做呢?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆