问题描述
在开发Java独立应用程序时，一些开发人员倾向于扩展JFrame类并实现（实现）某些actionlistener接口。 它不会违反oops中的泛化概念吗？还是抽象。 它也没有违反单一责任原则。
[编辑]违反oops中的概括概念，我的意思是“ is-a”关系无效。 继承更改为扩展类的类
1楼
这种常见的反模式带来了几个问题：
class Application extends JFrame implements ActionListener {}
相对于 ， ，
Application可能具有JFrame，但它仅应扩展JFrame以覆盖其现有功能。实现这样的接口可以导致 。 这增加了确保仅在上构造和操作Swing GUI对象的问题。
关于 ，
JFrame是Window一种特殊化 ，用作 。 不要将与混淆。关于 ，尽管Swing具有的和抽象性，但
JFrame显示出一致的派生。
对于一个 ，实现一个控制接口（例如ActionListener ）可能会很方便，但是一个复杂的应用程序可能需要多个 。
检查使用jmapviewer的示例。
另请参见 。
2楼
您的问题有点令人困惑且难以理解，因为您使用的是奇怪的术语。 这些句子是正确的，并且意味着：
- 一个班级扩展另一个班级
- 一个类实现一个接口
- 一个类从其父类继承方法
这些句子不合适，不清楚：
- 一个类继承另一个类
- 违反概括概念
尤其是没有代码的时候，我只能猜出您要问的是什么，但无论如何我都会尝试回答：
- 扩展JFrame并同时实现动作侦听器接口的类，因为它一次成为2件事违反了单一职责原则
- 扩展JFrame并同时包含一些与显示或配置JFrame不相关的逻辑的类，通过同时做两件事违反了单一职责原则。 它也违反了模型-视图-控制器的良好分离
- 一个扩展JFrame的类，但就其行为/实现而言，它主要不是JFrame，而是其他东西，那么它违反了JFrame的抽象，因此不应扩展JFrame，而应该包含它