继承 JFrame 违反泛化答案

【问题标题】：Inheriting JFrame violates Generalization继承 JFrame 违反泛化
【发布时间】：2015-07-18 11:18:15
【问题描述】：

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

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

【问题讨论】：

【解决方案1】：

这种常见的反模式带来了几个问题：

class Application extends JFrame implements ActionListener {}

给定一个preference for composition over inheritance，Application 可能有一个 JFrame，但它应该只扩展 JFrame 以覆盖其现有功能.
以这种方式实现接口会导致leaking this in a constructor。这加剧了确保 Swing GUI 对象仅在event dispatch thread 上构造和操作的问题。
关于generalization，JFrame 是Window 的专业化，用作top-level container。不要将containment hierarchy 与class hierarchy 混淆。
关于 single responsibility，尽管 Swing 的 history 和 cross-platform 抽象，JFrame API 显示出一致的推导。

实现一个控制接口，例如ActionListener，对于self-contained example 可能很方便，但一个复杂的应用程序可能需要多个controller。使用jmapviewer 的示例检查here。另见Why CS teachers should stop teaching Java applets。

【讨论】：

我没有混淆包含层次结构，但很好奇 IS-A 关系是否因此被违反？
对不起，如果我似乎 sententious 可能会造成混淆。基于API 和history，我想说JFrame 的推导是相当一致的。您是否看到特定的异常情况？
如果您能简要说明违反单一责任原则的情况，将接受答案

【解决方案2】：

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

这些句子不恰当，不清楚：

尤其是没有代码，我只能猜测你在问什么，但我还是试着回答：

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

【讨论】：