>问题
我需要覆盖该方法
@Override protected final void layoutChartChildren(double top, double left, double width, double height)
XYChart类的。 显然我不允许。
问题
为什么人们宣称方法为"最终"？这有什么好处吗？
这个答案只是JavaFX API设计者之一Richard Bair逐字引用的文本，该文本被发布在邮件列表中，以回答以下问题："为什么[JavaFX] API中几乎所有内容都是最终的？">
子类化打破了封装。这就是根本原因 您必须谨慎设计以允许子类化或禁止子类化。 将类的所有字段公开将给开发人员提供 功率增加 - 但当然这会破坏封装，所以我们 避免它。
我们在Swing中一直在打破人们。制作起来非常困难 即使是适度的错误修复 Swing 也不会破坏某人。更改 方法中的调用顺序，打破了人。当您的框架或 API 被数以百万计的程序使用，而程序作者没有 了解它们可能正在运行哪个版本的框架的方法 on(JRE 共享安装的诅咒！(，然后你会发现一个可怕的 很多智慧使一切最终化，你可以。它不是 只是为了保护自己的自由，它实际上创造了更好的产品 为每个人。你认为你想子类和覆盖，但这 有一个明显的缺点。框架作者不会 能够在未来为你做得更好。
不过还有更多。当你设计一个API时，你必须考虑 关于开发人员允许的所有内容的组合。当你 允许子类化，你打开了大量的附加 可能的故障模式，因此您需要小心。允许 子类，但限制超类允许重新定义的内容 减少故障模式。我在 API 设计中的理想之一是创建一个 具有尽可能多的功能的 API，同时减少 故障模式。这样做具有挑战性，同时还要提供足够的 开发人员可以灵活地做他们需要做的事情，如果我有 选择，我总是会错误地在 发布，因为您以后可以随时添加更多 API，但是一旦您 发布了一个 API 你被它困住了，否则你会破坏人。而在 在这种情况下，API 不仅意味着方法签名，还意味着 调用某些方法时的行为(正如 Josh 在 有效的爪哇(。
乔纳森描述的吸气/二传手方法问题是一个完美的 例。如果我们使这些方法非最终的，那么它确实允许 用于重写和记录调用的子类。但这就是它的全部好处 为。如果子类永远不会调用super，那么我们将被打破 (以及他们的应用程序！他们认为他们不允许某个 输入值，但不是。或者 getter 返回的值不是 属性对象包含的内容。或者侦听器通知没有 在正确的时间或正确的时间发生。或错误的实例 返回属性对象。
我非常喜欢两件事：最终和不变性。然而，GUI的趋势 有利于大类层次结构和可变状态：-(。但我们使用最终 和尽可能多的不变性。
一些信息：
- 最佳实践，因为 JavaFX setter/getter 是最终的？