所以在最近的一个回答中，有人评论了这一点（关于绘画）：
“这可能是 90% Swing 程序员的某种毛病：当他们制作自己的组件时，他们总是扩展 JPanel 而不是 JComponent。为什么呢？”
我对编程还很陌生，所以我认为现在称自己为 Swing 程序员还为时过早，因为我还没有找到自己的定位。但压倒一切JPanel这就是我被教导的方式。于是我开始寻找这个问题的答案"Why?"评论者的问题。这些是我找到的一些答案。
背景绘画是主要区别。JComponent 类不绘制其背景，因此您必须在重写的paintComponent 方法中绘制背景。相比之下，JPanel 有一个不透明的背景，可以通过调用其paintComponennt 方法来绘制。
有些程序员更喜欢扩展 JPanel 类，而不是扩展 JComponent。 JPanel 旨在成为一个可以包含其他组件的容器，但也可以在其上进行绘制。只有一处不同。面板是不透明的，这意味着它负责绘制其边界内的所有像素。实现此目的的最简单方法是通过在每个面板子类的 PaintComponent 方法中调用 super.paintComponent 来使用背景颜色绘制面板：
如果 opaque 属性设置为 true ...那么 Swing 绘制系统就不必浪费时间尝试在组件后面绘制，从而提高性能。
我认为最后一句话确实最好地解释了这一点。但除了不透明之外，还有其他有利的原因吗？“90%的Swing程序员都有这个毛病”的延伸JPanel而不是JComponent?
不透明度处理的差异并不是唯一的因素。
查看 JPanel 源代码会有所帮助，因为它只有大约 100 行。
所有构造函数最终都会调用这个构造函数。
不透明度和双缓冲默认为 true。
默认的 LayoutManager 是 FlowLayout，您可能需要也可能不需要。
public JPanel(LayoutManager layout, boolean isDoubleBuffered) {
setLayout(layout);
setDoubleBuffered(isDoubleBuffered);
setUIProperty("opaque", Boolean.TRUE);
updateUI();
}
Loy 等人在 O'Reilly 的 Java Swing 第 2 版中建议扩展 JComponent 以实现真正的自定义组件（第 1333 页），但也提到需要考虑 UI 委托。 JPanel 处理它自己的具体 AccessibleContext，而扩展 JComponent 的类则返回 null。
对于只读可视组件，我通常扩展 JComponent，但对于交互式组件，我可能会三思而后行，因为需要额外考虑可访问性。
Cheers,
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
