Java OOP 策略

Question

我有一个名为可视化数据结构的项目。我有这样的 OOP 设计。

Class VisualDataStructures extends JFrame
Class ControlPanel extends JPanel
Class CodePanel extends JPanel

Class VisualDataStructures 有 main.此类具有 Class ControlPanel 和 CodePanel 的实例。

Class ControlPanel 在 JMenuBar 中有名为“Load”的 JMenuItem。

类 CodePanel 有一个 JTextArea。

问题:
我需要在 ControlPanel 类中为名为“load”的 JMenuItem 设置一个 Action 监听器。当点击加载时，用户将进入文件所在的目录，然后文件将被加载并显示在CodePanel的JTextArea中。

我是否需要将从 VisualDataStructures 实例化的对象 CodePanel 传递到 ControlPanel 以便我使用该对象然后修改 JTextArea 的值？

有人知道更好的方法吗？谢谢。

Answer 1

在没有看到实际代码的情况下回答这个问题有点困难，但我仍然会尝试。也许如果您可以通过 Github、Bitbucket、Gist 或 Pastebin 以某种方式共享您的代码，我可以给出更好的答案。在 CodeReview stackexchange 而不是 StackOverflow 上执行此操作可能会更好。

总的来说，我觉得有那么多来自 GUI 父类的 extends 有点可疑。 扩展使用 可能有点反模式。首先，它可能会导致在微型应用程序中生成看似简单的代码，但从长远来看，它往往会混淆源代码，因为它鼓励混合使用业务逻辑和 UI。认为扩展是 OOP 的核心是一种误解。它不是。多态抽象以解耦和反转关键依赖关系，这是 OOP 的核心。扩展只是最重要的一个好东西，而且它被过度使用了。

说到这个，您可能听说过MVC - Model View Controller 。这是 UI 将事物分开的典型模式。

您不希望对 load 操作使用react的 ActionListener 直接知道 CodePanel，对于这样的依赖项来说，这太过分了具体的。您希望在两者之间有一个抽象，如接口(interface)，并引用该接口(interface)而不是 CodePanel。

当涉及到 ActionListener 和类似接口(interface)时，如果您还没有升级到 Java 8，您可能会对升级到 Java 8 感兴趣。像 ActionListener 这样只有一个抽象方法的接口(interface)是隐式功能接口(interface)，这意味着您可以使用 lambda 或方法引用。

总的来说，我认为始终牢记以下问题会有很大帮助:如果我用不同的 UI 工具包替换怎么办？即使它不是一个用例并且永远不会发生这种情况时，您为回答该问题所做的关注点解耦和分离会导致更加模块化、更好的设计，这些设计更易于理解和维护。最后，如果我用不同的 UI 工具包替换 UI 工具包会怎样？ 的问题导致设计遵循更多 SOLID 原则。

在处理 Swing 中的 ActionListener 时，您可能需要查看 interface Action 和 abstract class AbstractAction。它们提供了非常有趣的功能。如果使用得当，它们可以大大简化代码。