继承JFrame违反了泛化

Question

在开发java独立应用程序时，一些开发人员倾向于扩展JFrame类和实现（实现）一些actionlistener接口。它是否违反了oops和抽象中的泛化概念。它是否也违反了单一责任原则。

[编辑]通过违反oops中的泛化概念，我的意思是“is-a”关系变得无效。 继承一个更改为扩展类

的类

Answer 1

这种经常出现的反模式会带来一些问题：

class Application extends JFrame implements ActionListener {}

• 鉴于preference for composition over inheritance，Application可能拥有 JFrame，但它只能扩展 {{ 1}}覆盖其现有功能。

• 以这种方式实现接口可以导致leaking this in a constructor。这加剧了确保在event dispatch thread上仅构建和操作Swing GUI对象的问题。

• 关于generalization，JFrame是JFrame的专精，用作top-level container。请勿将containment hierarchy与class hierarchy混淆。

• 关于single responsibility，Window API显示了连贯的推导，尽管Swing的history和cross-platform抽象。

实施控制界面（例如JFrame）可能对self-contained example很方便，但复杂的应用程序可能需要多个controller。检查使用jmapviewer的示例here。另请参阅Why CS teachers should stop teaching Java applets。

Answer 2

你的问题有点令人困惑，难以理解，因为你使用的是奇怪的术语。这些句子是正确的，意思是：

• 一个类扩展了另一个类
• 一个类实现一个接口
• 一个类从其父类继承方法

这些句子不合适，不清楚：

• 一个类继承另一个类
• 违反概括概念

特别是没有代码，我只能猜出你在问什么，但我还是试着回答：

• 扩展JFrame并同时实现动作侦听器接口的类，通过一次两件事违反单一责任原则
• 一个扩展JFrame的类，同时包含一些与显示或配置JFrame无关的逻辑，通过同时执行两项操作违反了单一责任原则。它还违反了模型 - 视图 - 控制器的良好分离
• 一个扩展JFrame的类，但就其行为/实现而言，它主要不是JFrame而是其他东西，然后它违反了JFrame的抽象，它不应该扩展JFrame但可能包含它而不是