问题
我需要覆盖方法
@Override protected final void layoutChartChildren(double top, double left, double width, double height)
XYChart类的。显然我不被允许。
问题
为什么人们将方法声明为＆＃34; final＆＃34;？这有什么好处吗？
答案 0 :(得分：2)
这个答案只是JavaFX API设计师之一Richard Bair的文字逐字引用，该帖子已发布在邮件列表中以回答问题："Why is almost everything in the [JavaFX] API final?"
子类化打破封装。这是其根本原因 您必须谨慎设计以允许子类化或禁止它。 将一个类的所有字段公开给开发人员 增加功率 - 但当然这打破了封装，所以我们 避免它。
我们在Swing一直打破了人们。这很难做到 即使是适度的错误修复Swing而不会破坏某人。改变了 一种方法中的呼叫顺序，打破了人们。当你的框架或API 正在被数以百万计的程序使用，而程序作者则没有 了解他们可能正在运行的框架版本的方式 on（JRE共享安装的诅咒！），然后你发现很糟糕 你可能可以做到最后的很多智慧。它不是 为了保护自己的自由，它实际上创造了一个更好的产品 为所有人。你认为你想要子类和覆盖，但这 有一个明显的缺点。框架作者不会去 能在将来为你做好事。
但是还有更多。在设计API时，您必须考虑 关于开发人员允许的所有事物的组合。当你 允许子类化，你打开了大量额外的 可能的故障模式，因此您需要小心谨慎。允许一个 子类但限制超类允许重新定义的内容 减少故障模式。我在API设计中的一个理想是创建一个 具有尽可能多的功率的API同时减少数量 失败模式。这样做具有挑战性，同时也提供足够的 开发人员可以灵活地做他们需要做的事情，如果有的话 选择，我总是会错误地提供更少的API 发布，因为您以后可以随时添加更多API，但是一旦您完成 发布了一个你坚持使用它的API，否则你会破坏人们。并在 在这种情况下，API并不仅仅意味着方法签名，它意味着 调用某些方法时的行为（正如Josh指出的那样） 有效的Java）。
Jonathan描述的getter / setter方法问题是完美的 例。如果我们使这些方法不是最终的，那么它确实允许a 用于覆盖和记录调用的子类。但是这一切都很好 对于。如果子类永远不会调用super，那么我们就会被打破 （以及他们的应用程序！）。他们认为他们不允许某种情况 输入值，但他们不是。或者getter返回除了之外的值 属性对象包含什么。或听众通知没有 发生在正确或恰当的时间。或错误的实例 返回属性对象。
我真正喜欢的两件事：最终和不变性。但是，GUI会倾向于 支持大班级等级和可变状态:-)。但我们使用final 和尽可能多的不变性。
一些信息：