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

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

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

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

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

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

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

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

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

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

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

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

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

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