我经常发现自己想要做到这一点。当你想存储一些有用的信息或额外的状态时，它可能非常有用。为什么许多SWT控件不允许继承子类？
所以我的问题是，有一个很好/强烈的原因，为什么这是禁止的？
感谢
编辑： 非常感谢所有这些问题的答案。所以这听起来像是没有对或错的答案。
假设我接受这样的事实，这些类是不能被继承，什么的不打标控制类决赛，但禁止子类的点 - 有效地从编译时降级异常/错误运行时？
编辑^ 2： 看到我自己对此的回答：显然，这些类是可覆盖的，但需要overrider的明确确认。
感谢继承
它看起来没有任何人在任何答案中提到过这一点，但SWT确实提供了一个可覆盖的checkSubclass（）方法，正是引发了Unextenable异常的地方。要强制覆盖，您可以将该方法覆盖为禁用，并有效地扩展合法。我想打开这个选项是最终的原因，该类不是最终的，扩展错误不是编译时而是运行时。
设计成分是很难的，并会限制未来实施的变化（当然，如果你离开一些方法重写，并从其他方法调用它们）。禁止子类限制用户，但意味着编写健壮的代码更容易。
这跟随Josh Bloch的“继承或禁止设计”的建议。这是开发社区中的一个宗教话题 - 我同意这种观点，但其他人则倾向于尽可能地延伸。
创建可以安全分类的类是非常困难的。你必须考虑无尽的用例，并保护你的课程。我相信这是将API类标记为最终的一般原因。
至于你的后续问题：
什么不是标志着 控制级决赛中，但禁止 子类的点 - 有效降级的编译时 异常/错误 运行 - 时间？
如果SWT将Control类标记为最终类，那么SWT就不可能继承这个类。但他们必须在内部。所以他们将检查延迟到运行时间。
顺便说一句，如果你想要一个疯狂的黑客攻击，你仍然可以继承子类Control或任何其他SWT类，通过将你的子类放入org.eclipse.swt.widgets包。但我从来没有真的必须这样做。
的org.eclipse.swt.widgets.Widget.checkSubclass()的方法描述表示：
检查这一类可以被继承。
SWT类库仅用于特定的 受控点（最值得注意的是，当 实现新小部件时，Composite和Canvas）。此方法强制执行此规则，除非它被重写为 。
重要提示：通过提供这种方法的实现，它允许 子一类通常不允许子类是 创建的，实施者同意对事实 ，任何此类的子类很可能会失败负全部责任SWT版本之间，并将 强烈平台特定。不支持用户编写的以这种方式实现的类。
到允许SWT类以外的子类的能力旨在 纯粹是为了使那些没有在SWT开发团队来实现，以获得提前当 这些限制可以通过解决围绕具体限制 补丁球队。如果没有对 层次结构的亲密和详细的理解，则不应尝试子类别 。
抛出：SWTException
ERROR_INVALID_SUBCLASS - 如果该类不是允许子类
但是Eclipse本身以这种方式创建了我们的'Shell`类（从`Shell`继承），然后重写`checkSubclass（） `空身。我们这样做是否好（安全）？我有两个shell（`Shell_1`，`Shell_2`）。 `Shell_1`是`Shell_2`的父亲。我只想扩展`Shell_2`的`Shell`类，这样我就可以在`Shell_2`的构造函数中添加控件了。这是错误的方式吗？ – 2011-12-05 10:15:37