为什么Windows Forms / Swing框架偏爱继承而不是Composition?


12

今天,我的一位教授评论说,他发现奇怪的是,尽管SWT的哲学是通过合成来进行自己的控制,但Swing似乎更喜欢继承。

我几乎没有接触过这两个框架,但是从我记得在C#的Windows窗体中,通常可以扩展控件,就像Swing一样。

既然人们通常倾向于使用合成而不是继承,那么Swing / Windows Forms的人们为什么不偏爱使用合成而不是继承?


2
这些API出现的15到20年间发生了很多变化!渲染引擎没有神奇的XML胶水可以将屏幕对象与任意具体类的实例“回溯”中绑定;)

1
我看到的大多数Swing代码都按组成使用扩展名。我不确定您的教授在哪里获取他的数据。

我本人在网上看到了很多关于继承而不是合成的动摇-尽管大多是教程。但是Windows窗体实际上几乎完全是通过继承使用的!
2011年

Answers:


7

JComponent暴露了很多功能。如果JComponent一个接口和组件是通过组合实现的,那么简单的组件将需要数十个琐碎的方法包装器,例如

class MyComponent implements JComponent {
    JPanel panel;
    public boolean contains(int x, int y) {
        return panel.contains(x, y);
    }
    ...
}

有效率的原因,更喜欢继承而不是继承-重写不花任何钱(假设没有super通话),而花钱则额外INVOKEVIRTUAL。我不知道这是否影响了Swing的设计,但这是收藏类的一个大问题。


2

实际上,Swing Framework是根据Composite Design Pattern设计的。承认那里有很多继承,但是您通常会使用composition来组成自己的形式。也就是说,表单是中级容器和控件的组合。


“就是说,表格是中级容器和控件的组合。” 当然。但是我通常看到的是,当人们想要创建自己的窗口(或在Swing中调用的东西)时,他们将从窗口类继承而不是使用组合。
2011年

@吞噬的极乐世界是的。但是要创建表格,他们将使用合成。因此,这是一点点继承和很多组成。

@devoured,我认为这是一个案例,人们没有意识到他们使用的教程没有遵循最佳实践,因为它偏爱简洁。
彼得·泰勒

1

使用Java,仅因为所有内容都是虚拟的,最终使用继承容易得多。是否需要在JTable / JFrame中修复“功能”?扩展它,覆盖问题方法,然后在各处使用表/框架。

我认为对于WPF之类的东西来说,数据绑定是设计的主要功能,它使编写合成而不是继承变得容易得多。


“一切都是虚拟的 ” 是什么意思?
乔纳斯(Jonas)

在Java中,每个方法都是隐式虚拟的(可以重写)。在C#中,您必须将方法显式声明为virtual,并且要覆盖它,则必须将其显式声明为override。在Java中,您可以覆盖可见的所有内容,还可以提高其在子类中的可见性(可以在子类中公开受保护的方法!)
John Gardner

请注意final,即使基类本身不是,也不能覆盖Java中的方法final
PERP

没错,@ perp。但是在Java中,您必须竭尽全力(添加final)以防止虚拟。C#是相反的方式,您必须全力以赴地进行虚拟化。在标准Java运行时中,只有很小一部分标记为final。
约翰·加德纳

1

Bloch 在有效Java条款 17中提到,为继承而设计的类“必须记录其对可重写方法的自我使用”。此实现的标志是此实现的短语。您会在JTable和类中看到它JInternalFrame。这是Swing中通过设计进行继承的一种方法。


-2

从C#3.5开始,我们有一个称为扩展方法的概念,该概念允许使用合并而不是继承的概念。

在此过程中,我们只需添加一个扩展类就可以为现有类实现扩展功能,该扩展类将新功能呈现给现有类。

您可以在这里查阅更多详细信息


我看不到与创建新WinForms Control类的相关性。您能详细说明一下吗?
彼得·泰勒

@Peter:这不仅与Windows窗体类有关。这也可以从我们的代码中应用。您可以扩展任何现有的类,只需添加一个静态类,然后添加带有第一个参数的新方法,这样就可以链接基础对象。编译代码后,您将获得新添加的方法作为基类本身的方法。这就是组成所陈述的。希望我是对的..
Saravanan

1
我知道什么是扩展方法,它们有时很方便,但是这个问题是关于创建新类的不同方法的。
彼得·泰勒

@Peter:那我只能指出使用部分类,除了我所理解的以外,C#没有任何其他显着的功能。如果您知道任何事情,请告诉我。
Saravanan
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.