java 为什么不应该扩展 JFrame 和其他组件？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1143923/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why shouldn't you extend JFrame and other components?
提问by Thomas Owens
I've seen this come up here a few times, but in the postings I've seen, no one explained it. Why shouldn't I extend JFrame (or any component)? Are there conditions where I should extend a component, or is this a firm rule that you don't?
我已经在这里看到了几次，但是在我看到的帖子中，没有人解释它。为什么我不应该扩展 JFrame（或任何组件）？是否存在我应该扩展组件的条件，或者这是您不应该扩展的严格规则？
采纳答案by Yishai
Generally speaking, extending the component tends to be done strictly to use the component. This severely limits your options in unnecessary ways in terms of design, so that your classes can't extend different classes, you can't hide the JFrame's methods causing it to be more difficult to maintain and easier to trigger unexpected bugs when using the class.
一般来说，扩展组件趋于严格地使用组件。这在设计方面以不必要的方式严重限制了您的选择，使您的类无法扩展不同的类，您无法隐藏 JFrame 的方法，从而导致在使用类时更难维护并更容易触发意外错误.
Typically the intention is strictly to use the class to draw a frame, and composition is preferred over inheritance.
通常意图是严格使用类来绘制框架，并且组合优于继承。
That being said, subclassing should be fine when you intend your subclass to add project-specific functionality to the Frame (such as convenience methods and the like) where the subclass would be used instead of the Frame itself, but used as a frame in general, not as a view of a specific frame in the application.
话虽如此，当您打算让子类向 Frame 添加项目特定的功能（例如便利方法等）时，子类化应该没问题，其中子类将用于代替 Frame 本身，但通常用作框架，而不是作为应用程序中特定框架的视图。
回答by Tom Hawtin - tackline
Prefer composition over inheritance. All the usual reasons. Composition forces less dependencies between code.
更喜欢组合而不是继承。所有常见的原因。组合强制减少代码之间的依赖性。
Swing, and event AWT, components are hideously complicated. You don't want to be getting into that mess. You can easily override methods accidentally. In cases where you do need to override methods, it's difficult to see where that is done if it is amongst normal code.
Swing 和事件 AWT 组件非常复杂。你不想陷入那种混乱。您可以轻松地意外覆盖方法。在您确实需要覆盖方法的情况下，如果它是在正常代码中，则很难看到它在哪里完成。
回答by AlbertoPL
If your application REALLY is just a JFrame, go ahead and extend it. However, it's best to use object composition rather than inheritance if you are simply usinga JFrame.
如果您的应用程序真的只是一个 JFrame，请继续扩展它。但是，如果您只是使用JFrame ，最好使用对象组合而不是继承。
If your object extends some other object you would have no choice in the matter, as an example.
例如，如果您的对象扩展了某个其他对象，您将别无选择。
回答by Alex B
I don't see the problem as long as you are extending the class and can preserve the "is-a" aspects of inheritance.
只要您扩展类并且可以保留继承的“is-a”方面，我就看不到问题。
When you extend a JPanel but your new object is not a true specialization of JPanel, that is where you get into trouble. But if you create a new SpeciallyFormattedJLabelthat extends JLabel, I see no problem with that.
当您扩展 JPanel 但您的新对象不是 JPanel 的真正特化时，这就是您遇到麻烦的地方。但是，如果您创建一个SpeciallyFormattedJLabel扩展的 new JLabel，我认为没有问题。
回答by B.K.
I know this is an old post, but I just came across it and I gotta tell you... extending limited my options of calling certain actions of the object. I'm actually rewriting some parts of the code now to get rid of the damage that extended has caused me. Unless I'm writing a one-file program, I'm not going to use extended again.
我知道这是一篇旧帖子，但我刚刚遇到它，我必须告诉你......扩展限制了我调用对象某些操作的选项。我现在实际上正在重写代码的某些部分，以消除扩展对我造成的损害。除非我正在编写一个单文件程序，否则我不会再次使用扩展。
